USB stick

[john...@nospam.com.au]

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?

[Shmuel Metz]

In <c1.2c.3Xj52y$0...@PC1.BIGPOND.COM>, on 10/18/2012

at 09:45 AM, john...@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?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

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 spam...@library.lspace.org

[Doug Bissett]

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).

Next, get:

> http://hobbes.nmsu.edu/download/pub/os2/system/USBcfgb071-eCS-only.wpi

or

> http://hobbes.nmsu.edu/download/pub/os2/system/USBcfgb071.zip

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.

> http://www.dfsee.com/dfsee/

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)

[Doug Bissett]

On Thu, 18 Oct 2012 15:02:50 UTC, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:

> In <c1.2c.3Xj52y$0...@PC1.BIGPOND.COM>, on 10/18/2012
> at 09:45 AM, john...@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

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?
>


--

[Dave Yeo]

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

[john...@nospam.com.au]

In <SKfw30zmCGmZ-p...@blah.blah.com>, "Doug Bissett" <dougb007!SP...@telus.net> writes:
>On Thu, 18 Oct 2012 09:45:14 UTC, john...@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.

[Pete]

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).

HTH,
Pete

--

[James J. Weinkam]

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.

[Barry Landy]

On Thu, 18 Oct 2012, James J. Weinkam wrote:

:>

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

[James J. Weinkam]

Barry Landy wrote:
>
> 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.

[Shmuel Metz]

In <SKfw30zmCGmZ-p...@blah.blah.com>, on 10/18/2012

at 06:44 PM, "Doug Bissett" <dougb007!SP...@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.

[Barry Landy]

On Mon, 22 Oct 2012, Shmuel (Seymour J.) Metz wrote:

:>In <SKfw30zmCGmZ-p...@blah.blah.com>, on 10/18/2012

:> at 06:44 PM, "Doug Bissett" <dougb007!SP...@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).

[Doug Bissett]

On Mon, 22 Oct 2012 13:50:59 UTC, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:

> In <SKfw30zmCGmZ-p...@blah.blah.com>, on 10/18/2012
> at 06:44 PM, "Doug Bissett" <dougb007!SP...@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.

[Shmuel Metz]

In <SKfw30zmCGmZ-p...@blah.blah.com>, on 10/23/2012

at 05:18 AM, "Doug Bissett" <dougb007!SP...@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..

[Barry Landy]

On Tue, 23 Oct 2012, Shmuel (Seymour J.) Metz wrote:

:>In <SKfw30zmCGmZ-p...@blah.blah.com>, on 10/23/2012

:> at 05:18 AM, "Doug Bissett" <dougb007!SP...@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.

[Doug Bissett]

On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:

> In <SKfw30zmCGmZ-p...@blah.blah.com>, on 10/23/2012
> at 05:18 AM, "Doug Bissett" <dougb007!SP...@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.

[Alex Taylor]

On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
<spam...@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.

--
Alex Taylor
Fukushima, Japan
http://www.altsan.org

Please take off hat when replying.

[Doug Bissett]

On Thu, 25 Oct 2012 03:27:01 UTC, "Alex Taylor"
<mai...@reply.to.address> wrote:

> On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
> <spam...@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.

[James J. Weinkam]

Alex Taylor wrote:
> On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
> <spam...@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.

[Doug Bissett]

On Thu, 25 Oct 2012 21:27:11 UTC, "James J. Weinkam" <j...@cs.sfu.ca>
wrote:

> Alex Taylor wrote:
> > On Tue, 23 Oct 2012 13:50:34 UTC, Shmuel (Seymour J.) Metz
> > <spam...@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.

[Dave Yeo]

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]

On Fri, 26 Oct 2012 22:51:08 UTC, Dave Yeo <dave....@gmail.com>
wrote:

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.

[Dave Yeo]

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