In <c1.2c.3Xj52y$...@PC1.BIGPOND.COM>, on 10/18/2012
at 09:45 AM, johns...@nospam.com.au said:
>In the hope of being able to read USB sticks,
Formatted how? The only issue that I had with thumb drives was
nonstandard formatting, which DFSEE cleaned up quite nicely. Note that
both FAT32 and NTFS require you to install an IFS:
IFS=Q:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
>What else should I do to enable reading the sticks?
If the partition information is clean, just download and install the
IFS. If the partition information is flaky, by DFSEE and analyze how
the data stick is formatted, then ask for support in correcting the
problems.
I had it easier because I wasn't concerned with preserving existing
information. Does your situation allow formatting a new data stick,
using a copy of windoze to copy the old data stick and then reading
from the new one?
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamt...@library.lspace.org
On Thu, 18 Oct 2012 09:45:14 UTC, johns...@nospam.com.au wrote:
> In the hope of being able to read USB sticks, I installed the 186 drivers.
> The mobo has 2 controllers each with 2 ports. Only 2 ports are external.
> Drives object shows 2 additional floppy drives which cannot be accessed.
> Sysinfo/2>Disks>F: reports IFS is unknown.
> What else should I do to enable reading the sticks?
The two additinal floppy drives are the result of the /floppies: parameter on the BASEDEV=USBMSD.ADD
line in CONFIG.SYS, being set to more than zero (if you have two icons, it is probably set to 2). That should be set to zero, unless you do use a USB floppy drive. It has nothing to do with reading USB sticks.
On that same line, is the /removables: parameter, which should be set to the sum of:
The number of physical USB ports, plus the number of slots in any multicard USB reader that may be attached, plus one. eCS 2.x defaults that number to 8, but there may be cases where that is not enough, and
it may be more than what you need (but that won't hurt anything).
depending on whether you have eCS or not. That will verify that you have the correct lines in CONFIG.SYS, and help you repair any discrepancies.
Now, IF your USB stick is larger than 2 GB, you do need to properly prepare them for use with LVM (if you don't use LVM, you have other problems, and I am not sure what you need to do). The easy way to get it right, is to use DFSEE to configure the stick. I recommend doing that part, even if the stick is less than 2 GB, but you should be able
to use them without that, as long as they are formatted with a file system that eCS understands.
You then need a way to get the stick to mount, when you insert it. You
can use the command line (I assume that you use LVM):
> LVM.EXE /REDISCOVERPRM
after inserting the device. That should recognize the presence of the device, and assign a drive letter.
OR, you can use the program USBMSDD.EXE (in \eCS\boot, in later versions of eCS), or USBMON.EXE (the one in \OS2\BOOT, NOT the one in \OS2 - that is for printers) for earlier versions of eCS, or OS/2. Put
an icon for it in the Startup folder, so it will always run. This will
automatically mount the drive, and assign a drive letter, as long as the device was shut down properly.
There is also a widget available for eCenter, or XCenter, if you use one of them. This widget does have some problems.
Most important, is to be sure the EJECT the device, before removing it. If you use the widget, you must use the widget to remove it (pretty much the same as in windows). If you use the other methods, RMB on the drive icon, and select EJECT from the menu. Wait for the icon to go away before removing the device. If you don't do that, you can damage the data, and leave the device in a "dirty" state. Next time you try to mount it, you will need to do a CHKDSK on it, or, you may need to use windows to fix it, if it is formatted as FAT32.
HTH...
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
On Thu, 18 Oct 2012 15:02:50 UTC, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> In <c1.2c.3Xj52y$...@PC1.BIGPOND.COM>, on 10/18/2012
> at 09:45 AM, johns...@nospam.com.au said:
> >In the hope of being able to read USB sticks,
> Formatted how? The only issue that I had with thumb drives was
> nonstandard formatting, which DFSEE cleaned up quite nicely. Note that
> both FAT32 and NTFS require you to install an IFS:
Personally, I recommend NOT using /EAS with FAT32. Using it very much complicates trying to maintain compatibility with windows. Windows FAT32 does not know about OS/2's EAs, so if windows does anything with
the file (move, copy, delete) the EAs get messed up in OS/2. EAs are almost never needed for data files anyway.
I also find that REMing the CACHEF32.EXE line, in CONFIG.SYS is a good
idea. The driver works more reliably, and faster, without it.
To clarify: It is highly recommended to not use the OS/2 NTFS driver, and if you do, use it only in READ ONLY mode.
> >What else should I do to enable reading the sticks?
> If the partition information is clean, just download and install the
> IFS. If the partition information is flaky, by DFSEE and analyze how
> the data stick is formatted, then ask for support in correcting the
> problems.
DFSEE now has a script that does a wonderful job of setting up USB sticks. You will lose the data, so be sure to copy anything you want to keep before doing it. It is not freeware, but you can use it for 30
days for free (unsupported, which can get you into BIG trouble if you don't know what you are doing). After that, I highly recommend buying it (it is good for most modern platforms), and after you pay, excellent support is available if you ever need it.
> I had it easier because I wasn't concerned with preserving existing
> information. Does your situation allow formatting a new data stick,
> using a copy of windoze to copy the old data stick and then reading
> from the new one?
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Doug Bissett wrote:
> Most important, is to be sure the EJECT the device, before removing
> it. If you use the widget, you must use the widget to remove it
> (pretty much the same as in windows). If you use the other methods,
> RMB on the drive icon, and select EJECT from the menu. Wait for the
> icon to go away before removing the device. If you don't do that, you
> can damage the data, and leave the device in a "dirty" state. Next
> time you try to mount it, you will need to do a CHKDSK on it, or, you
> may need to use windows to fix it, if it is formatted as FAT32.
There's also the command line eject.exe that comes with OS/2 IIRC, eject n: wait a few seconds then remove.
Dave
In <SKfw30zmCGmZ-pn2-MetrkOoHN...@blah.blah.com>, "Doug Bissett" <dougb007!S...@telus.net> writes:
>On Thu, 18 Oct 2012 09:45:14 UTC, johns...@nospam.com.au wrote:
Thanks so much to Metz and Doug.
I found and installed the fat32.ifs and DaniDASD144, with no
switches in config.sys.
OS/2 now reads Win written files and Win reads OS/2 written files.
On Thu, 18 Oct 2012 21:30:22 UTC, Dave Yeo <dave.r....@gmail.com> wrote:
> Doug Bissett wrote:
> > Most important, is to be sure the EJECT the device, before removing
> > it. If you use the widget, you must use the widget to remove it
> > (pretty much the same as in windows). If you use the other methods,
> > RMB on the drive icon, and select EJECT from the menu. Wait for the
> > icon to go away before removing the device. If you don't do that, you
> > can damage the data, and leave the device in a "dirty" state. Next
> > time you try to mount it, you will need to do a CHKDSK on it, or, you
> > may need to use windows to fix it, if it is formatted as FAT32.
> There's also the command line eject.exe that comes with OS/2 IIRC, eject > n: wait a few seconds then remove.
> Dave
I use cmd files (called from an xwp widget which presents a whole series
of cmd files, one for each removable drive letter I use). Each filename is "ejectX.cmd", with x being the applicable drive letter. Never had any
problems (I've rarely used the Eject menu option and never the special widget which has been causing so much grief of late). On my system, it takes about 5-10 seconds for the thing to be recognized after being plugged in.
Syntax for ejectX.cmd:
eject X:
pause
exit
The cmd file pauses when the ejection process is complete (the indicator
LED on the thumb drive/memory stick goes out at the same time).
Assuming all your USB/MSD/IFS/etc statements are installed and have the correct paramters, for any thumb drive/memory stick partition larger than 2gb (I think that's the magic number -- it's been a while), it's necessary to create LVM volume(s), assign a drive letter to each volume,
and write this [LVM] information to the drive regardless of which file system you are going to use (FAT32, HPFS, JFS). DFSee is best for doing this. This also works for CF, SD, SDHC, etc. cards. If exFAT is involved, the thing won't work because there is no exFAT driver for OS/2
(I'd like to say "yet" here).
Dave Yeo wrote:
> Doug Bissett wrote:
>> Most important, is to be sure the EJECT the device, before removing
>> it. If you use the widget, you must use the widget to remove it
>> (pretty much the same as in windows). If you use the other methods,
>> RMB on the drive icon, and select EJECT from the menu. Wait for the
>> icon to go away before removing the device. If you don't do that, you
>> can damage the data, and leave the device in a "dirty" state. Next
>> time you try to mount it, you will need to do a CHKDSK on it, or, you
>> may need to use windows to fix it, if it is formatted as FAT32.
> There's also the command line eject.exe that comes with OS/2 IIRC, eject n: wait a few seconds then remove.
> Dave
No. Wait until the command prompt reappears then remove.
In my experience, if the eject command completes and the command prompt reappears, you can remove your device and the data is safe no matter what the widget claims.
My experience has also been that if you use the widget to eject and it says "ok to remove," your data is safe even if the widget claims that the device was improperly removed when you unplug it.
On Thu, 18 Oct 2012, James J. Weinkam wrote:
:>Dave Yeo wrote:
:>> Doug Bissett wrote:
:>> > Most important, is to be sure the EJECT the device, before removing
:>> > it. If you use the widget, you must use the widget to remove it
:>> > (pretty much the same as in windows). If you use the other methods,
:>> > RMB on the drive icon, and select EJECT from the menu. Wait for the
:>> > icon to go away before removing the device. If you don't do that, you
:>> > can damage the data, and leave the device in a "dirty" state. Next
:>> > time you try to mount it, you will need to do a CHKDSK on it, or, you
:>> > may need to use windows to fix it, if it is formatted as FAT32.
:>> :>> There's also the command line eject.exe that comes with OS/2 IIRC, eject n:
:>> wait a few seconds then remove.
:>> Dave
:>
:>No. Wait until the command prompt reappears then remove.
:>
:>In my experience, if the eject command completes and the command prompt
:>reappears, you can remove your device and the data is safe no matter what the
:>widget claims.
:>
:>My experience has also been that if you use the widget to eject and it says
:>"ok to remove," your data is safe even if the widget claims that the device
:>was improperly removed when you unplug it.
:>
On the other hand, click on the DRIVE object, R click on the drive icon, select EJECT and remove the stick when the drive icon vanishes.
-- Barry Landy Email: Remove nospam in from address
192, Gilbert Road, Cambridge CB4 3PB
> On the other hand, click on the DRIVE object, R click on the drive icon,
> select EJECT and remove the stick when the drive icon vanishes.
True enough if all is going well. However, clicking on the drives widget in the ecenter or attempting to open the drives object in the Local System folder can freeze the workplace shell if any drive is not responding.
In <SKfw30zmCGmZ-pn2-pzE5rsyzI...@blah.blah.com>, on 10/18/2012
at 06:44 PM, "Doug Bissett" <dougb007!S...@telus.net> said:
>Personally, I recommend NOT using /EAS with FAT32. Using it very >much complicates trying to maintain compatibility with windows.
If I were a windoze user then I might agree with you. I use thumb
drives for
1. Files downloaded using the library's broadband
2. Backup of my eCS system
3. Transfer of data between eCS systems.
>DFSEE now has a script that does a wonderful job of setting up USB >sticks.
I know; I was the instigator for that script. But if you need access
to existing data, qulified assistance is available and the first shot
is included in the cost of the software.
>It is not freeware
It's also not expensive, and it's well worth the cost.
>(unsupported, which can get you into BIG trouble if you don't >know what you are doing).
It's not running unsupported that's dangerous, it's trying to do
things on your own without requesting expert assistance. That's
dangerous even if you're supported. If you trust Jan enough to buy his
software, trust him when he says something is dangerous. The
turnaround time on his assistance is reasonably short.
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamt...@library.lspace.org
On Mon, 22 Oct 2012, Shmuel (Seymour J.) Metz wrote:
:>In <SKfw30zmCGmZ-pn2-pzE5rsyzI...@blah.blah.com>, on 10/18/2012
:> at 06:44 PM, "Doug Bissett" <dougb007!S...@telus.net> said:
:>
:>>Personally, I recommend NOT using /EAS with FAT32. Using it very :>>much complicates trying to maintain compatibility with windows.
:>
:>If I were a windoze user then I might agree with you. I use thumb
:>drives for
:>
:> 1. Files downloaded using the library's broadband
:>
:> 2. Backup of my eCS system
:>
:> 3. Transfer of data between eCS systems.
:>
:>>DFSEE now has a script that does a wonderful job of setting up USB :>>sticks. :>
:>I know; I was the instigator for that script. But if you need access
:>to existing data, qulified assistance is available and the first shot
:>is included in the cost of the software.
:>
:>>It is not freeware
:>
:>It's also not expensive, and it's well worth the cost.
:>
:>>(unsupported, which can get you into BIG trouble if you don't :>>know what you are doing).
:>
:>It's not running unsupported that's dangerous, it's trying to do
:>things on your own without requesting expert assistance. That's
:>dangerous even if you're supported. If you trust Jan enough to buy his
:>software, trust him when he says something is dangerous. The
:>turnaround time on his assistance is reasonably short.
:>
:>
Just to second all the comments about DFSEE and Jan's support. Excellent software and fantastic service. AND not expensive.
(I have become sufficiently "expert" that I am prepared to do some things without his help, but if I need it he usually responds within a day, and if it is a destoyed HDD I am prepared to wait that long).
-- Barry Landy Email: Remove nospam in from address
192, Gilbert Road, Cambridge CB4 3PB
On Mon, 22 Oct 2012 13:50:59 UTC, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> In <SKfw30zmCGmZ-pn2-pzE5rsyzI...@blah.blah.com>, on 10/18/2012
> at 06:44 PM, "Doug Bissett" <dougb007!S...@telus.net> said:
> >Personally, I recommend NOT using /EAS with FAT32. Using it very > >much complicates trying to maintain compatibility with windows.
> If I were a windoze user then I might agree with you. I use thumb
> drives for
Windows never knows about the problems, it just causes them because the EAs are not attached to the files on a FAT32 drive.
> 1. Files downloaded using the library's broadband
> 2. Backup of my eCS system
> 3. Transfer of data between eCS systems.
I suspect that none of those actually needs to use EAs, unless you are
just copying files from your boot volumes directly to the FAT32 thumb drive for backup. If you don't use those thumb drives with windows, you would be better off to format them as JFS (or HPFS). If you write to them with windows, there are no EAs to worry about.
> >DFSEE now has a script that does a wonderful job of setting up USB > >sticks.
> I know; I was the instigator for that script. But if you need access
> to existing data, qulified assistance is available and the first shot
> is included in the cost of the software.
> >It is not freeware
> It's also not expensive, and it's well worth the cost.
I agree with that...
> >(unsupported, which can get you into BIG trouble if you don't > >know what you are doing).
> It's not running unsupported that's dangerous, it's trying to do
> things on your own without requesting expert assistance. That's
> dangerous even if you're supported. If you trust Jan enough to buy his
> software, trust him when he says something is dangerous. The
> turnaround time on his assistance is reasonably short.
Jan basically says that anything that you can do with the DFSEE menus is pretty safe, but the user should have some basic idea of what is going to happen when they say OK to something like deleting a partition, or they will have big problems. Of course, once the partition is deleted, it would be wise to ask Jan how to get it back, and it definitely helps to run the DFSdisk Analysis program, and store
the output somewhere safe, before doing anything else with DFSEE.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
In <SKfw30zmCGmZ-pn2-eM5rXVpwF...@blah.blah.com>, on 10/23/2012
at 05:18 AM, "Doug Bissett" <dougb007!S...@telus.net> said:
>I suspect that none of those actually needs to use EAs,
Some OS/2 applications record, e.g., file type, in an EA, so I do need
them for transferring files between eCS systems. Of course, I could
zip them first, but that seems like a lot of bother in some cases..
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamt...@library.lspace.org
On Tue, 23 Oct 2012, Shmuel (Seymour J.) Metz wrote:
:>In <SKfw30zmCGmZ-pn2-eM5rXVpwF...@blah.blah.com>, on 10/23/2012
:> at 05:18 AM, "Doug Bissett" <dougb007!S...@telus.net> said:
:>
:>>I suspect that none of those actually needs to use EAs,
:>
:>Some OS/2 applications record, e.g., file type, in an EA, so I do need
:>them for transferring files between eCS systems. Of course, I could
:>zip them first, but that seems like a lot of bother in some cases..
:>
:>
zipping is what I do for that reason. The files themselves start and finish on an HPFS drive or a JFS one.
-- Barry Landy Email: Remove nospam in from address
192, Gilbert Road, Cambridge CB4 3PB
On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> In <SKfw30zmCGmZ-pn2-eM5rXVpwF...@blah.blah.com>, on 10/23/2012
> at 05:18 AM, "Doug Bissett" <dougb007!S...@telus.net> said:
> >I suspect that none of those actually needs to use EAs,
> Some OS/2 applications record, e.g., file type, in an EA, so I do need
> them for transferring files between eCS systems. Of course, I could
> zip them first, but that seems like a lot of bother in some cases..
In a lot of cases, it is faster to ZIP the files to a USB (thumb) drive, simply because there is less data to transfer over the slow USB
interface (and FAT32 is extremely slow, even in windows). Of course, with small files, it is more bother than not. Perhaps I have just been
lucky, but I have never had a problem with not maintaining the EAs while transfering files by FAT32. Most OS/2 programs will simply create them again, if they are missing (the desktop is another matter). Of course, I rarely transfer files between OS/2 systems, using FAT32. That is almost always for transfer between windows systems, and OS/2. Windows couldn't care less if there are EAs attached. Most of the time, I use RSync, SAMBA, or (Peter Moylan's) FTP, to transfer files between OS/2 systems. PEER networking works too, but it doesn't support files larger than 2 GB. All of those (except PEER) will also work between windows, and OS/2, as well as between windows machines.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> >I suspect that none of those actually needs to use EAs,
> Some OS/2 applications record, e.g., file type, in an EA, so I do need
> them for transferring files between eCS systems. Of course, I could
> zip them first, but that seems like a lot of bother in some cases..
If you disable EAs, don't try to run a REXX script off a FAT32 drive.
It'll destroy the file. REXX tries to write the tokenized code to the
EAs and for some reason can't cope when FAT32 has them turned off.
<mail...@reply.to.address> wrote:
> On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz > <spamt...@library.lspace.org.invalid> wrote:
> > >I suspect that none of those actually needs to use EAs,
> > Some OS/2 applications record, e.g., file type, in an EA, so I do need
> > them for transferring files between eCS systems. Of course, I could
> > zip them first, but that seems like a lot of bother in some cases..
> If you disable EAs, don't try to run a REXX script off a FAT32 drive.
> It'll destroy the file. REXX tries to write the tokenized code to the
> EAs and for some reason can't cope when FAT32 has them turned off.
I can't imagine why I would want to do that, but you are probably right (not sure why it would destroy the file). However, if you copy the REXX to an EA capable file system (before it is destroyed), and run it, it will simply recreate the EAs.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Alex Taylor wrote:
> On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
> <spamt...@library.lspace.org.invalid> wrote:
>>> I suspect that none of those actually needs to use EAs,
>> Some OS/2 applications record, e.g., file type, in an EA, so I do need
>> them for transferring files between eCS systems. Of course, I could
>> zip them first, but that seems like a lot of bother in some cases..
> If you disable EAs, don't try to run a REXX script off a FAT32 drive.
> It'll destroy the file. REXX tries to write the tokenized code to the
> EAs and for some reason can't cope when FAT32 has them turned off.
That does not happen on my desktop machine, which has only JFS volumes, but has the FAT32 driver installed without the /EAS parameter.
I just tried copying a REXX script to three different USB mass storage devices: 1) an 8GB real USB stick formatted FAT32. 2) an 8GB SDHC card formatted FAT32 in a Targus card reader/writer. 3) a 1GB SD card formatted FAT in the same card reader/writer.
In all three cases the script ran correctly and no files were corrupted. In the case of the FAT card, I deleted the existing EAs before copying the file to the card. EABROWSE confirmed that in cases 1) and 2) there were no EAs either before or after running the REXX command. In case 3) there were no EAs initially, but running the script caused the ESs to be recreated and the EA DATA. SF file showed up in the root of the card. I would have expected this same thing to have happened in cases 1) and 2). Perhaps the interpretation of omitting the /EAS parameter for FAT32.IFS is, "No EAs in any way, shape or form, so smoke on your pipe and put that in."
My desktop machine is running eCS2.0GA using the USB and FAT32 drivers that came with the system. So far I have not found it necessary to install Lars' updated USB drivers.
> Alex Taylor wrote:
> > On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
> > <spamt...@library.lspace.org.invalid> wrote:
> >>> I suspect that none of those actually needs to use EAs,
> >> Some OS/2 applications record, e.g., file type, in an EA, so I do need
> >> them for transferring files between eCS systems. Of course, I could
> >> zip them first, but that seems like a lot of bother in some cases..
> > If you disable EAs, don't try to run a REXX script off a FAT32 drive.
> > It'll destroy the file. REXX tries to write the tokenized code to the
> > EAs and for some reason can't cope when FAT32 has them turned off.
> That does not happen on my desktop machine, which has only JFS volumes, but has the FAT32 driver installed without the > /EAS parameter.
> I just tried copying a REXX script to three different USB mass storage devices: 1) an 8GB real USB stick formatted > FAT32. 2) an 8GB SDHC card formatted FAT32 in a Targus card reader/writer. 3) a 1GB SD card formatted FAT in the same > card reader/writer.
1 and 2 are effectively the same thing. FAT is a little different.
> In all three cases the script ran correctly and no files were corrupted.
Actually, that is what I would expect. I am not sure why Alex had a problem with that.
>In the case of the FAT card, I deleted the > existing EAs before copying the file to the card. EABROWSE confirmed that in cases 1) and 2) there were no EAs either > before or after running the REXX command. In case 3) there were no EAs initially, but running the script caused the ESs > to be recreated and the EA DATA. SF file showed up in the root of the card. I would have expected this same thing to > have happened in cases 1) and 2). Perhaps the interpretation of omitting the /EAS parameter for FAT32.IFS is, "No EAs in > any way, shape or form, so smoke on your pipe and put that in."
That is absolutely correct. FAT, on OS/2, does create EAs, in EA DATA.
SF. You cannot turn that feature off. The main "problem" with FAT, is that OS/2 stores long file names in the EAs, so only the short file names are left when the EAs get disconnected. Windows, of course, knows nothing about long file names, so all it uses is the short file names. Confusing.
If you use the /EAS parameter with the FAT32 driver, it also creates the EAs in EA DATA. SF. If you don't use /EAS, no EA support, of any kind is available. FAT32 does maintain the long file names, because they are not only in the EAs, as with FAT.
The "problem" arises, for both FAT and FAT32, when windows does anything with any files that have OS/2 style EAs (other than simply read them). The EAs get disconnected from the file, and windows doesn't know, or care. When you reboot to OS/2, those files no longer have a linkage to the EAs that are stored in EA DATA. SF, so they effectively have no EAs, but when you run CHKDSK on the drive, it finds EAs, that no longer have files, and must fix that (by deleting the EAs). This basically means that it is a waste of effort to store EAs on a FAT, or FAT32 drive, if windows ever does anything, other than read, the files. It also creates a drive maintenance headache, because it is wise to run CHKDSK occassionaly to clean up the mess. Better, IMO, to just not use EAs in the first place (of course, you have no choice with FAT).
> My desktop machine is running eCS2.0GA using the USB and FAT32 drivers that came with the system. So far I have not > found it necessary to install Lars' updated USB drivers.
Perhaps not "necessary", but I would suggest that you should try them.
It has been my experience that they generally run much better than the
old IBM drivers, and I am pretty sure that they will be in future versions of eCS, so it would be good to test them to be sure that they
work with your machine(s). If they don't, you have an opportunity to get them fixed. If they do, you have gained performance.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Doug Bissett wrote:
> The "problem" arises, for both FAT and FAT32, when windows does
> anything with any files that have OS/2 style EAs (other than simply
> read them). The EAs get disconnected from the file, and windows
> doesn't know, or care. When you reboot to OS/2, those files no longer
> have a linkage to the EAs that are stored in EA DATA. SF, so they
> effectively have no EAs, but when you run CHKDSK on the drive, it
> finds EAs, that no longer have files, and must fix that (by deleting
> the EAs). This basically means that it is a waste of effort to store
> EAs on a FAT, or FAT32 drive, if windows ever does anything, other
> than read, the files. It also creates a drive maintenance headache,
> because it is wise to run CHKDSK occassionaly to clean up the mess.
> Better, IMO, to just not use EAs in the first place (of course, you
> have no choice with FAT).
Does Windows really ignore FAT EAs now? My newest is Win2k which I've seen actually fix EA problems during chkdsk and as far as I know even XP still understands EAs. NTFS even has a special stream just for EAs.
Have to experiment with my sons Win7
Dave
> Doug Bissett wrote:
> > The "problem" arises, for both FAT and FAT32, when windows does
> > anything with any files that have OS/2 style EAs (other than simply
> > read them). The EAs get disconnected from the file, and windows
> > doesn't know, or care. When you reboot to OS/2, those files no longer
> > have a linkage to the EAs that are stored in EA DATA. SF, so they
> > effectively have no EAs, but when you run CHKDSK on the drive, it
> > finds EAs, that no longer have files, and must fix that (by deleting
> > the EAs). This basically means that it is a waste of effort to store
> > EAs on a FAT, or FAT32 drive, if windows ever does anything, other
> > than read, the files. It also creates a drive maintenance headache,
> > because it is wise to run CHKDSK occassionaly to clean up the mess.
> > Better, IMO, to just not use EAs in the first place (of course, you
> > have no choice with FAT).
> Does Windows really ignore FAT EAs now? My newest is Win2k which I've > seen actually fix EA problems during chkdsk and as far as I know even XP > still understands EAs. NTFS even has a special stream just for EAs.
> Have to experiment with my sons Win7
> Dave
NTFS knows about EAs, but AFAIK, windows doesn't use them. I am not sure about the OS/2 NTFS driver. You can use EAs when networked to a windows machine (at least using SAMBA - I am not sure about PEER, if you can convince it to connect), as long as the file system being used
by windows is NTFS.
In windows, FAT32 does not know about EAs. In OS/2, only OS/2 knows about EAs on a FAT32 drive, but only if you specify /EAS on the IFS line in CONFIG.SYS. You cannot use EAs over the network, if the windows file system is FAT32.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Dave Yeo wrote:
> Does Windows really ignore FAT EAs now? My newest is Win2k which I've
> seen actually fix EA problems during chkdsk and as far as I know even XP
> still understands EAs. NTFS even has a special stream just for EAs.
> Have to experiment with my sons Win7
> Dave
A quick test on Win7, scandisk removed EA DATA .SF and WP ROOT .SF, without running scandisk, just moving them to a Win7 desktop (NTFS) and back, the EAs also got lost.
So it seems the Win7 FAT driver does not preserve EAs, just removes them if given the chance.
Dave
