On Sun, 16 Jan 2005 16:40:38 UTC in comp.os.os2.bugs,
di540@FreeNet.Carleton.CA (Maximo Lachman) wrote:

>
> The HD will quickly slow down to about a tick every other second after the square clock mouse icon appears, that can still be moved around as usual.

These symptoms usually mean it is crashing and logging an entry in
\popuplog.os2 for each crash. Checking that file might tell you what is
crashing and why or at least give an idea of what's going on.

--
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley at dsl dot pipex dot com

Sir:

Maximo Lachman wrote:
> Ciao,
>
> As it happens on a day like today, I now have to wonder if there's an
> alternative to PMshell, that might indirectly show what's wrong, if
> installed over it, as well as an app/script that will directly
> diagnose the problem.
>
> The 4.00 (no FPs) system I'm upkeeping will boot to a Workplace
> Shell, but not PMshell, whether via the WPS command line or a full
> boot.
>
> The HD will quickly slow down to about a tick every other second
> after the square clock mouse icon appears, that can still be moved
> around as usual.
>
> What ways can be used to narrow down the problem 1st, before trying
> to adjust things?
>
> What alternative shells can be tried out 1st on a mirrored boot
> partition, which only implement a subset of PMshell, esp. ones that
> don't have "workspace areas", need ini registries or use shadows, but
> can still do most of PMshell's jobs?
>
WAG, most blue screen of death is a sign that the multimedia sub system
is fubarred. Is not the crashes occuring about the time that the system
startup sound should be playing, just before painting of the desktop? I
would rem all the devices that have mmos2 in their paths in config.sys,
done from a cmd line boot. If the system now boots, it means that
mmpm2.ini file is bad. I would uninstall multimedia from the maintaince
boot (after you've modified config.s to rem its multimedia statements,
and then reboot and reinstall. Get some fixpacks installed, suggest fp
15 ASAP as there are bugs in that original build of Warp 4.
--
Bill
Thanks a Million!

"William L. Hartzell" (wlhartzell@comcast.net) writes:
> WAG, most blue screen of death is a sign that the multimedia sub system
> is fubarred. Is not the crashes occuring about the time that the system
> startup sound should be playing, just before painting of the desktop? I
> would rem all the devices that have mmos2 in their paths in config.sys,
> done from a cmd line boot. If the system now boots, it means that
> mmpm2.ini file is bad. I would uninstall multimedia from the maintaince
> boot (after you've modified config.s to rem its multimedia statements,
> and then reboot and reinstall. Get some fixpacks installed, suggest fp
> 15 ASAP as there are bugs in that original build of Warp 4.

Yes, as in the Soundblaster driver that's supplied. But that was fixed
using the generic ESS drivers on a WarpUP CD. Applying its FP didn't
get the SB to work anyway, and caused other things to fail. In any
case, z! still runs over slippm just fine, so it seems unlikely to be
an mmos2 bug, and at this stage, the only way a FP will get applied
is as part of IBM's or Serenity's package, and only if they aren't
using 3rd party bugware to instal packages like Opera or IBM's new
browser. But thanks for the guess. (My next post will have the gory
details.)
--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.

"Trevor Hemsley" (Trevor-Hemsley@mytrousers.dsl.pipex.com) writes:
> di540@FreeNet.Carleton.CA (Maximo Lachman) wrote:
>> The HD will quickly slow down to about a tick every other second after the square clock mouse icon appears, that can still be moved around as usual.
>
> These symptoms usually mean it is crashing and logging an entry in
> \popuplog.os2 for each crash. Checking that file might tell you what is
> crashing and why or at least give an idea of what's going on.

I just ran pmshell in WPS, & it produced the log entry:
------------------------------------------------------------
01-16-2005 16:32:44 SYS2070 PID 002a TID 0001 Slot 002f
G:\OS2\PMSHELL.EXE
FXFILE
193
------------------------------------------------------------

01-16-2005 16:32:45 SYS2070 PID 002a TID 0001 Slot 002f
G:\OS2\PMSHELL.EXE
FXFILE
193
------------------------------------------------------------

01-16-2005 16:32:45 SYS3170 PID 002a TID 0001 Slot 002f
G:\OS2\PMSHELL.EXE
c0010001
1ee3718c
EAX=00000001 EBX=00000000 ECX=00000000 EDX=00656dbc
ESI=00000000 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=1fffffff
ES=0053 ESACC=d0f3 ESLIM=1fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fa1454e CSACC=d0df CSLIM=1fffffff
SS:ESP=0053:0004f8f0 SSACC=d0f3 SSLIM=1fffffff
EBP=0004f8f8 FLG=00012202

FXFILE.SOM 0001:0000718c

ÍÍÍÍ End of File ÍÍÍÍ

What's really weird is that pmshell is now aborting more quickly compared to the 1st time this occurred on Friday, which recorded 666 entries every 7 seconds - as if it were due to some virus.
But it looks to be another problem in FaxWorks.
The last time I had a problem with it, I ran splinst.exe to instal PMfax over FaxWorks, which seemed to work very well.
Please advise on what to do next.
BTW, by typing mode co128,34 & tedit popuplog.os2, it was like watching a movie of the time & PID racing away when depressing "PgDn".
The 1st & last in the series follow:
------------------------------------------------------------
01-14-2005 16:34:13 SYS2070 PID 000b TID 0001 Slot 0027
G:\OS2\PMSHELL.EXE
FXFILE
193
------------------------------------------------------------

01-14-2005 16:34:13 SYS2070 PID 000b TID 0001 Slot 0027
G:\OS2\PMSHELL.EXE
FXFILE
193
------------------------------------------------------------

01-14-2005 16:34:14 SYS3170 PID 000b TID 0001 Slot 0027
G:\OS2\PMSHELL.EXE
c0010001
1ee7718c
EAX=00000001 EBX=00000000 ECX=00000000 EDX=00656dbc
ESI=00000000 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=1fffffff
ES=0053 ESACC=d0f3 ESLIM=1fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fa2454e CSACC=d0df CSLIM=1fffffff
SS:ESP=0053:0004f8f0 SSACC=d0f3 SSLIM=1fffffff
EBP=0004f8f8 FLG=00012202

FXFILE.SOM 0001:0000718c
------------------------------------------------------------
[snip thousands of lines]
------------------------------------------------------------
01-14-2005 17:50:01 SYS2070 PID 02a4 TID 0001 Slot 0027
G:\OS2\PMSHELL.EXE
FXFILE
193
------------------------------------------------------------

01-14-2005 17:50:01 SYS2070 PID 02a4 TID 0001 Slot 0027
G:\OS2\PMSHELL.EXE
FXFILE
193
------------------------------------------------------------

01-14-2005 17:50:02 SYS3170 PID 02a4 TID 0001 Slot 0027
G:\OS2\PMSHELL.EXE
c0010001
1ee7718c
EAX=00000001 EBX=00000000 ECX=00000000 EDX=00656dbc
ESI=00000000 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=1fffffff
ES=0053 ESACC=d0f3 ESLIM=1fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fa2454e CSACC=d0df CSLIM=1fffffff
SS:ESP=0053:0004f8f0 SSACC=d0f3 SSLIM=1fffffff
EBP=0004f8f8 FLG=00012202

FXFILE.SOM 0001:0000718c

--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.

On Sun, 16 Jan 2005 22:41:55 UTC in comp.os.os2.bugs,
di540@FreeNet.Carleton.CA (Maximo Lachman) wrote:

> I just ran pmshell in WPS, & it produced the log entry:
> ------------------------------------------------------------
> 01-16-2005 16:32:44 SYS2070 PID 002a TID 0001 Slot 002f
> G:\OS2\PMSHELL.EXE
> FXFILE
> 193

Look for duplicate fxfile.som files in your (I guess) LIBPATH
directories - though I suspect this won't help as, on my system, it's
registered as a WPS class with explicit path info in it (i.e. FxFile
F:\FAXWORKS\FXFILE.SOM). Chkdsk maybe? Mine is

12-01-00 6:00p 52582 2968 FxFile.som

Don't know how you get rid of this one you need PMshell to be running
to be able to deregister WPS classes so about the only thing I can think
of is to replace the file with a working one if it's been corrupted.

--
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley at dsl dot pipex dot com

"Trevor Hemsley" (Trevor-Hemsley@mytrousers.dsl.pipex.com) writes:
> di540@FreeNet.Carleton.CA (Maximo Lachman) wrote:
>
>> I just ran pmshell in WPS, & it produced the log entry:
>> ------------------------------------------------------------
>> 01-16-2005 16:32:44 SYS2070 PID 002a TID 0001 Slot 002f
>> G:\OS2\PMSHELL.EXE
>> FXFILE
>> 193
>
> Look for duplicate fxfile.som files in your (I guess) LIBPATH
> directories - though I suspect this won't help as, on my system, it's

True: I had moved \bonuspak\ to a separate partition that was also shared by the boot partition mirror, probably because it contained user data, rather than os\2-specific files.

> registered as a WPS class with explicit path info in it (i.e. FxFile
> F:\FAXWORKS\FXFILE.SOM). Chkdsk maybe? Mine is

It's on an HPFS partition - chkdsk didn't fix it.

> 12-01-00 6:00p 52582 2968 FxFile.som
>
> Don't know how you get rid of this one you need PMshell to be running
> to be able to deregister WPS classes so about the only thing I can think
> of is to replace the file with a working one if it's been corrupted.

Yes, it was corrupted - trying to open it w/tedit produced the same ticking behavior.
Luckily I had also copied the entire \bonuspak\faxworks to a floppy & PMshell now boots after replacing that file.
Thanks for your help.
How should I move \bonuspak\ back to the boot partition, so that all registry entries get changed?
I assume w/PMshell running, but using "pickup" instead of drag & drop?
Also, what does the "2968" refer to? The new file has "0" instead.
--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.

On Mon, 17 Jan 2005 06:35:05 UTC in comp.os.os2.bugs,
di540@FreeNet.Carleton.CA (Maximo Lachman) wrote:

> > 12-01-00 6:00p 52582 2968 FxFile.som
[snip]
> Yes, it was corrupted - trying to open it w/tedit produced the same ticking behavior.

Hmmm, that sounds ominous. I would guess that it wasn't making more
popuplog entries this time so that may be an indicatrion that the
corruption had a physical cause like the HD going west!

> How should I move \bonuspak\ back to the boot partition, so that all registry entries get changed?

Safest method? Uninstall/reinstall.

> Also, what does the "2968" refer to? The new file has "0" instead.

That column in a DIR output is the number of bytes of extended
attributes. It's probably the icon that's to be associated with fax
files at a guess.

--
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley at dsl dot pipex dot com

"Trevor Hemsley" (Trevor-Hemsley@mytrousers.dsl.pipex.com) writes:
> di540@FreeNet.Carleton.CA (Maximo Lachman) wrote:
>
>> > 12-01-00 6:00p 52582 2968 FxFile.som
> [snip]
>> Yes, it was corrupted - trying to open it w/tedit produced the same ticking behavior.
>
> Hmmm, that sounds ominous. I would guess that it wasn't making more
> popuplog entries this time so that may be an indicatrion that the
> corruption had a physical cause like the HD going west!

At least the drive is dying slowly.
It suffered a crash due to over-heating that corrupted a lot of files which were found by chkdsk, & a few which were removed.
Luckily, only the data partition on the outermost cylinders was affected.
I entirely backed up the OS partitions to an IDE drive, and some of the data folders, the rest will go onto another SCSI drive, perhpas optical, when I get the time.
I'll try to take advantage of the "spin down" timeouts in BIOS for IDE, but not shut down the PC

>> How should I move \bonuspak\ back to the boot partition, so that all registry entries get changed?
>
> Safest method? Uninstall/reinstall.

In that case, I'll let sleeping dogs lie.

>> Also, what does the "2968" refer to? The new file has "0" instead.
>
> That column in a DIR output is the number of bytes of extended
> attributes. It's probably the icon that's to be associated with fax
> files at a guess.

I added the icon used for the old FaxWorks data files, since that where the original copy was, but that increased the number to 3087.
Perhaps the PMfax version wasn't using the same icon?
Well, I just checked the FaxWorks backup floppy in a PMshell icon view, and the same old icon appears there!
That floppy does have an ea.data.sf file - how does one display that data for non-HPFS drives?
I guess I could have made it a system file before copying it, but is there any better way to keep the EAs?

--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.

On Tue, 18 Jan 2005 20:19:45 UTC, di540@FreeNet.Carleton.CA (Maximo
Lachman) wrote:

> I added the icon used for the old FaxWorks data files, since that where the original copy was, but that increased the number to 3087.
> Perhaps the PMfax version wasn't using the same icon?
> Well, I just checked the FaxWorks backup floppy in a PMshell icon view, and the same old icon appears there!
> That floppy does have an ea.data.sf file - how does one display that data for non-HPFS drives?

The same as if it were HPFS or JFS.

> I guess I could have made it a system file before copying it, but is there any better way to keep the EAs?
>

There is no need to handle ea data. sf! This file is nothing than a
place holder. Even when you use DosCopy() the EAs will be copied. So
Copy files from FAT to HPFS copies the EAs - but not ea data.s sf.
When you copies files from HPFS or JFS to a FAT drive ea data. sf gets
created implicity.

In EA aware filesystems EAs are bounded to the file/directory
directly. As FAT has nothing that can do that the file ea data. sf
gets created to fullify the requirements for the filesystem, means
reserve clusters in FAT for the data EAs are. It is done by the OS/2
FAT filesystem implicity.

copy and xcopy know how to copy EAs without to access ea data. sf
themself.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

"Herbert Rosenau" (os2guy@pc-rosenau.de) writes:
> Lachman) wrote:
>
>> I added the icon used for the old FaxWorks data files, since that where the original copy was, but that increased the number to 3087.
>> Perhaps the PMfax version wasn't using the same icon?
>> Well, I just checked the FaxWorks backup floppy in a PMshell icon view, and the same old icon appears there!
>> That floppy does have an ea.data.sf file - how does one display that data for non-HPFS drives?
>
> The same as if it were HPFS or JFS.

The point is that "dir" doesn't work the same.
Supposedly there's a /R switch in DOS sessions, but that still doesn't work, not even on HPFS partitions.

>> I guess I could have made it a system file before copying it, but is there any better way to keep the EAs?
>>
> There is no need to handle ea data. sf! This file is nothing than a

Even if there's no need, I'd still like to know how to extract the EA data at a command line.

> Copy files from FAT to HPFS copies the EAs - but not ea data.s sf.
> When you copies files from HPFS or JFS to a FAT drive ea data. sf gets
> created implicity.

On 4.00, when moving back from the FAT floppy to an HPFS partition, the EAs did not get copied.
But when copying via drag & drop to the floppy originally, they did.

> In EA aware filesystems EAs are bound to the file/directory
> directly. As FAT has nothing that can do that the file ea data. sf
> gets created to fullify the requirements for the filesystem, means
> reserve clusters in FAT for the data EAs are. It is done by the OS/2
> FAT filesystem implicity.
>
> copy and xcopy know how to copy EAs without to access ea data. sf themself.

certainly seems to when going from HPFS over to FAT (but not vice versa).
On the C: drive is a copy onto HPFS of a Windows system that just barely fit on a 128 MB FAT partition.
After a few years of use, I just coped it back to the same size FAT partition, and it wouldn't fit.
Scandisk shows plenty of holes, yet says that there is no fragmentation.
Those holes must be sectors for the ea system file.
I'll delete it to see what Scandisk reports.
Shoould I expect any problems from OS/2 during the next boot?
--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.

On Thu, 20 Jan 2005 02:18:29 UTC, di540@FreeNet.Carleton.CA (Maximo
Lachman) wrote:

> > There is no need to handle ea data. sf! This file is nothing than a
>
> Even if there's no need, I'd still like to know how to extract the EA data at a command line.

On HOBBES there are some EA browsers around. To hande EAs in your
program you should look at DosPathInfo (file not already open,
required for directory EAs or file EAs when you only interested in
EAS) or DosFileInfo() (file already open, required when you have
already a file handle).

> > copy and xcopy know how to copy EAs without to access ea data. sf themself.
>
> certainly seems to when going from HPFS over to FAT (but not vice versa).
> On the C: drive is a copy onto HPFS of a Windows system that just barely fit on a 128 MB FAT partition.
> After a few years of use, I just coped it back to the same size FAT partition, and it wouldn't fit.
> Scandisk shows plenty of holes, yet says that there is no fragmentation.
> Those holes must be sectors for the ea system file.
> I'll delete it to see what Scandisk reports.
> Shoould I expect any problems from OS/2 during the next boot?

The answer is a bit complex, please read on:

So long the data on a FAT partition is used only by DOS programs you
may still remove any EA from them as NO DOS program knows that EAs
exists.

When you have NOT used an OS/2 program that uses itself EAs you can
somply remove the EAs.

To remove the EAs you can do it by either remove "ea_data. sf" on FAT.
This will result in
- dead program objects you have created on your desktop or a folder on
it.
- loosing any settings you may have tone to program objects, program
file objects, data objects.
But it is not critical as you can remove the dead program objects and
you can create new ones when you needs them.

Anyway you can split EAs from an directory or file using eautil.exe,
save them separately and restore them at a later stage problemless
using the same tool with different parameters. On HPFS or JFS this is
the only chance to get EAs removed from a file or directory without
writing an own tool to do so.

As sayed DOS, Windows and other OSes knows nothing about EAs. 'EA
DATA. SF' gets created from OS/2 on that filesystems (yes, you can see
them even on NTFS, FAT32, raiser,..... when you access these
filesystems over network using the WPS). Removing that file will reset
anything in that filesystem to the state it had before the WPS had
seen that. It is definitely harmless to the data - but may influence
the views on them the WPS serves you.

Under OS/2 there are rare programs using EAs - except the WPS that
uses them extensive. From sight of the WPS any EA it uses has a save
default that gets set when there is no EA already. So destroying the
EAs (either by removing 'EA DATA. SF' or splitting them from theyr
source (eautil.exe) does no harm - except on the views (program start,
icon, details, tree view) and theyr settings.

Now back to the problem you have:
- use eautil.exe to split the EAs from the files and directories.
- Save the result files somewhere on another drive.
You may remove the resulting files when you are sure you would never
use the EAs.
That would be the case when you exactly knows that you have never
changed
the settings of an object or you can live with the defaults.
- copy the partiton to its destination place
- use eautil.exe to attach the EAs back.
You can do this step at any time _before_ you attaches the data
using the WPS.
Or you can ommit that step when you can live with the defaults the
WPS sets.

The WPS uses EAs to give you the best possible comfort in vieing data
representation. So I would say that you have created lots of DATA
files and directories on that drive over the time that logical drive
was hosted on HPFS instead of FAT. You may even had only extend files
to hold some more bytes than before you copied it from FAT to HPFS.
You should know that a file that gets extended one singe byte will
extend vby up to 32MB (1 cluster) on disk under FAT whereas it gets
only 1024 (2 sectors) wider on HPFS.

HPFS allocates disk space in double sectors (1024 bytes) whereas FAT
allocates space in clusters (4, 8, 16, 32 MB) when the used size of a
file exceeds the block size by appending a single byte to a file.

FAT has a maximal number of entries in the root directory - HPFS has
not.
So copying HPFS to FAT can fail on the whole number of entries in
the root directory
The minimum occupied size of a file differs significantly:
HPFS: 1024 bytes (2 sectors) or a multiple integer
FAT: depending on the size of the drive beginning with 4KB up to 32
MB.
This has a high influence of the number of files storeable on the
drive.
This has too a high influence of the used space on disk.
So copying HPFS to FAT can fail on the extensive use of more
sectors
on FAT than on HPFS based on the extensive wasting of space for
partly used clusters (FAT) instead of free double sectors on HPFS)

EAs would there only a problem when the original FAT spoace was even
nearly 100% in use. Because the resulting 'EA DATA. SF' under OS/2
would not so increase in size that it would fill any free space on a
FAT drive when it gets created during (x)copy that not all data should
fit.

I'm sure that you have created and modified lots of files since you
have copied the disk from FAT to HPFS and that the number of used
sectors converted to FAT uses significant more space than it had used
since you moved the data from FAT to HPFS. You needs more FAT clusters
now than years ago to get any data back to FAT - EAs are not a problem
on that.

You may have more luck to get any data stored back by DECREASING the
size of the FAT partiton to the next lower cluster size as the number
of wasted sectors is shrinking significantly by decreasing the size of
a cluster can win lots of free space. The size of a partiton gets
defined by a multiple of the size a single track occupies. The size of
a cluster is defined by M$ in a way that this number fits in a 16 bit
word in the head of the FAT table. So a little FAT drive has a low
number of sectors cmbined into one cluster and a very big FAT drive
has a big number of sectors combined into one cluster. Resulting in
wasting more sectors for bigger drives than for smaller ones. I left
it to you to find the documentation about thet on google or somewhere.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

Maximo Lachman wrote:
>
> Even if there's no need, I'd still like to know how to extract the EA data at a command line.
>
Check the command reference for EAUTIL.

"Herbert Rosenau" (os2guy@pc-rosenau.de) writes:
> Lachman) wrote:
>>"Herbert Rosenau" (os2guy@pc-rosenau.de) writes:
>> > copy and xcopy know how to copy EAs without to access ea data. sf themself.
>> certainly seems to when going from HPFS over to FAT (but not vice versa).

I just tried an xcopy from FAT to HPFS in a DOS session, & it refused to copy over ea data. sf but it seems that a new one was created at the target.

>> On the C: drive is a copy onto HPFS of a Windows system that just barely fit on a 128 MB FAT partition.
>> After a few years of use, I just coped it back to the same size FAT partition, and it wouldn't fit.
>> Scandisk shows plenty of holes, yet says that there is no fragmentation.
>> Those holes must be sectors for the ea system file.
>> I'll delete it to see what Scandisk reports.

It was Defrag not Scandisk, and it reports fragmentation afterwards.

>> Shoould I expect any problems from OS/2 during the next boot?

Yes: Starting w/a sys0281 at the command line.
Chkdsk /f is recommended to remake the EA file, which led to hundreds of messages like:
C:\WP ROOT. SF attempted to claim an extended attribute that does not exist
The error was corrected.

> So long the data on a FAT partition is used only by DOS programs you
> may still remove any EA from them as NO DOS program knows that EAs
> exists.
> When you have NOT used an OS/2 program that uses itself EAs you can
> somply remove the EAs.
> To remove the EAs you can do it by either remove "ea_data. sf" on FAT.
> This will result in
>-dead program objects you have created on your desktop or a folder on it.
>-loosing settings to program objects, program file objects, data objects.
> But it is not critical as you can remove the dead program objects and you can create new ones

I didn't have either of those problems, just the sys0281.

> Anyway you can split EAs from an directory or file using eautil.exe,
> save them separately and restore them at a later stage problemless
> using the same tool with different parameters. On HPFS or JFS this is
> the only chance to get EAs removed from a file or directory without
> writing an own tool to do so.

It seems you'd have to write one for batch processing all files.
Is this the same eautil supplied Warp 4?

> As sayed DOS, Windows and other OSes knows nothing about EAs. 'EA
> DATA. SF' gets created from OS/2 on that filesystems (yes, you can see
> them even on NTFS, FAT32, raiser,..... when you access these
> filesystems over network using the WPS). Removing that file will reset
> anything in that filesystem to the state it had before the WPS had
> seen that. It is definitely harmless to the data - but may influence
> the views on them the WPS serves you.

It even gets created under DOS sessions when copying files over from HPFS partitions.

> Under OS/2 there are rare programs using EAs - except the WPS that
> uses them extensive. From sight of the WPS any EA it uses has a save
> default that gets set when there is no EA already.

So don't create any objects in WPS to be stored on FAT or the ea data will mushroom.
Also, don't delete such objects in pure DOS, or their ea data will remain.

> Now back to the problem you have:
> - use eautil.exe to split the EAs from the files and directories.

There's probably a clever CLI way to do this, but I settled for:
attrib -r -h -s ea*.* (in PC DOS)
erase ea*.* /p

>FAT has a maximal number of entries in the root directory - HPFS has not.
> So copying HPFS to FAT can fail on the whole number of entries in
> the root directory
> The minimum occupied size of a file differs significantly:
> HPFS: 1024 bytes (2 sectors) or a multiple integer
> FAT: depending on the size of the drive beginning with 4KB up to 32MB.
> This has a high influence of the number of files storeable on the drive.
> This has too a high influence of the used space on disk.
> So copying HPFS to FAT can fail on the extensive use of more sectors
> on FAT than on HPFS based on the extensive wasting of space for
> partly used clusters (FAT) instead of free double sectors on HPFS)
>
> EAs would there only a problem when the original FAT spoace was even nearly 100% in use.

It was nearly 100%, except that 127 MB on HPFS holds more data than FAT16.

> You may have more luck to get any data stored back by DECREASING the
> size of the FAT partiton to the next lower cluster size as the number
> of wasted sectors is shrinking significantly by decreasing the size of
> a cluster can win lots of free space. The size of a partiton gets
> defined by a multiple of the size a single track occupies. The size of
> a cluster is defined by M$ in a way that this number fits in a 16 bit
> word in the head of the FAT table. So a little FAT drive has a low
> number of sectors cmbined into one cluster and a very big FAT drive
> has a big number of sectors combined into one cluster. Resulting in
> wasting more sectors for bigger drives than for smaller ones. I left
> it to you to find the documentation about thet on google or somewhere.

I had to do this originally to split the original 1.2GB Windows C: partition into two 127MB partitions.
The cluster size originally was 32K, & afterwards 2048 bytes, which is the smallest for "FAT16>32MB".
You'd think that you could get 1024 for<32MB, but it goes back up to 4096.
I did find a way to hack 1024 into it & allegedly works up to 64MB:
http://groups-beta.google.com/group/...a194de0baec44d
1) Format a FAT partition (less than 64M).
2) Use a disk editor to modify the byte at offset 0D of the boot sector
You'll see 04 there, change it to 02. This tells DOS or OS/2 that
you want 2 sectors/cluster instead of 4.
3) Re-format the partition. When FORMAT reads the Boot sector, it will see
a VALID BPB, and will use the values there instead of default values.
--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.

On Sat, 22 Jan 2005 17:36:34 UTC, di540@FreeNet.Carleton.CA (Maximo
Lachman) wrote:

>
> "Herbert Rosenau" (os2guy@pc-rosenau.de) writes:
> > Lachman) wrote:
> >>"Herbert Rosenau" (os2guy@pc-rosenau.de) writes:
> >> > copy and xcopy know how to copy EAs without to access ea data. sf themself.
> >> certainly seems to when going from HPFS over to FAT (but not vice versa).
>
> I just tried an xcopy from FAT to HPFS in a DOS session, & it refused to copy over ea data. sf but it seems that a new one was created at the target.

As sayed 'ea data. sf' is nothing than a placeholder on FAT. ON HPFS
it is absolutely useless. Even the files 'ea data. sf' itself is NOT
used on FAT. It is only a placeholder to occupy clusters reserved for
EAs. The file itself is nothing than a placeholder! Don't play with
placeholders - the system will know how to handle them.

> >> On the C: drive is a copy onto HPFS of a Windows system that just barely fit on a 128 MB FAT partition.
> >> After a few years of use, I just coped it back to the same size FAT partition, and it wouldn't fit.
> >> Scandisk shows plenty of holes, yet says that there is no fragmentation.
> >> Those holes must be sectors for the ea system file.
> >> I'll delete it to see what Scandisk reports.
>
> It was Defrag not Scandisk, and it reports fragmentation afterwards.
>
> >> Shoould I expect any problems from OS/2 during the next boot?

Maybe, yes. FAT is a very dumb filessystem. It likes to get fragmented
very easy.

> Yes: Starting w/a sys0281 at the command line.
> Chkdsk /f is recommended to remake the EA file, which led to hundreds of messages like:
> C:\WP ROOT. SF attempted to claim an extended attribute that does not exist
> The error was corrected.

wp root. sf is for EAs of the root directory (there is physically no
entry in the filesystem. Be happy that chkdsk corrects that.

> > So long the data on a FAT partition is used only by DOS programs you
> > may still remove any EA from them as NO DOS program knows that EAs
> > exists.
> > When you have NOT used an OS/2 program that uses itself EAs you can
> > somply remove the EAs.
> > To remove the EAs you can do it by either remove "ea_data. sf" on FAT.
> > This will result in
> >-dead program objects you have created on your desktop or a folder on it.
> >-loosing settings to program objects, program file objects, data objects.
> > But it is not critical as you can remove the dead program objects and you can create new ones
>
> I didn't have either of those problems, just the sys0281.

This is not critical as the WPS will create it magically when it does
not exist. The only you can loose on that is the EAs of the drives
object itself. This object itself owns save defaults. So you can easy
change them using the WPS.

> > Anyway you can split EAs from an directory or file using eautil.exe,
> > save them separately and restore them at a later stage problemless
> > using the same tool with different parameters. On HPFS or JFS this is
> > the only chance to get EAs removed from a file or directory without
> > writing an own tool to do so.
>
> It seems you'd have to write one for batch processing all files.
> Is this the same eautil supplied Warp 4?

Yes.

> > As sayed DOS, Windows and other OSes knows nothing about EAs. 'EA
> > DATA. SF' gets created from OS/2 on that filesystems (yes, you can see
> > them even on NTFS, FAT32, raiser,..... when you access these
> > filesystems over network using the WPS). Removing that file will reset
> > anything in that filesystem to the state it had before the WPS had
> > seen that. It is definitely harmless to the data - but may influence
> > the views on them the WPS serves you.
>
> It even gets created under DOS sessions when copying files over from HPFS partitions.

That is one of the magics of OS/2.

> > Under OS/2 there are rare programs using EAs - except the WPS that
> > uses them extensive. From sight of the WPS any EA it uses has a save
> > default that gets set when there is no EA already.
>
> So don't create any objects in WPS to be stored on FAT or the ea data will mushroom.
> Also, don't delete such objects in pure DOS, or their ea data will remain.

No. The WPS uses ea data. sf on FAT to store the EAs. (x)copy handles
the EAs properly.
But be sure that they get overwritten from the source when you copies
already existent files from one disk to the other - in any case.

> > Now back to the problem you have:
> > - use eautil.exe to split the EAs from the files and directories.
>
> There's probably a clever CLI way to do this, but I settled for:
> attrib -r -h -s ea*.* (in PC DOS)
> erase ea*.* /p

No need for DOS here. The same works in an OS/2 window. But as sayed
you'll loose the EAs of ALL files then - but not on HPFS/JFS, because
ea data. sf on HPFS/JFS is useless.

> >FAT has a maximal number of entries in the root directory - HPFS has not.
> > So copying HPFS to FAT can fail on the whole number of entries in
> > the root directory
> > The minimum occupied size of a file differs significantly:
> > HPFS: 1024 bytes (2 sectors) or a multiple integer
> > FAT: depending on the size of the drive beginning with 4KB up to 32MB.
> > This has a high influence of the number of files storeable on the drive.
> > This has too a high influence of the used space on disk.
> > So copying HPFS to FAT can fail on the extensive use of more sectors
> > on FAT than on HPFS based on the extensive wasting of space for
> > partly used clusters (FAT) instead of free double sectors on HPFS)
> >
> > EAs would there only a problem when the original FAT spoace was even nearly 100% in use.
>
> It was nearly 100%, except that 127 MB on HPFS holds more data than FAT16.

So you have a new task to do: clean up the data on that HPFS drive.
Means remove anything you have no need anymore to win enough free
space that gives you room on the FAT drive. Or better give up the idea
to go back to FAT. HPFS is quite more reliable than FAT.

Try to shrink the FAT to 126 MB. As 127 is one partially track more
than the size of a full cylinder (7 MB) on big disks format tries to
round up - giving you the next bigger cluster size as needed for 126.

When that does not help and you can't remove a significant number of
files to shrink the number of used sectors your only chance is to
extend the FAT drive to some more MB knowing that some of the
extension will be wasted by bigger clusters so you have to extend
more.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

On Sat, 22 Jan 2005 20:39:55 UTC, "The OS/2 Guy"
wrote:

> As sayed 'ea data. sf' is nothing than a placeholder on FAT. ON HPFS
> it is absolutely useless. Even the files 'ea data. sf' itself is NOT
> used on FAT. It is only a placeholder to occupy clusters reserved for
> EAs. The file itself is nothing than a placeholder! Don't play with
> placeholders - the system will know how to handle them.

See:

http://www.tavi.co.uk/os2pages/eadata.html

for more details...

"The OS/2 Guy" (os2guy@pc-rosenau.de) writes:
> Lachman) wrote:
>> I just tried an xcopy from FAT to HPFS in a DOS session, & it refused to copy over ea data. sf but it seems that a new one was created at the target.
>
> As sayed 'ea data. sf' is nothing than a placeholder on FAT. ON HPFS
> it is absolutely useless. Even the files 'ea data. sf' itself is NOT
> used on FAT. It is only a placeholder to occupy clusters reserved for
> EAs. The file itself is nothing than a placeholder! Don't play with
> placeholders - the system will know how to handle them.

I was letting the system xcopy *.* from one FAT partiotion to another.
It does make sense for it to create a new ea file rather than copy the old one.

> Means remove anything you have no need anymore to win enough free
> space that gives you room on the FAT drive. Or better give up the idea
> to go back to FAT. HPFS is quite more reliable than FAT.

I'd like the logical Windows/DOS partitions on the backup drive to be FAT so that PowerBoot can boot them via floppy for certain programs that won't run in virtual sessions.

> Try to shrink the FAT to 126 MB. As 127 is one partially track more
> than the size of a full cylinder (7 MB) on big disks format tries to
> round up - giving you the next bigger cluster size as needed for 126.

The backup drive is small and doesn't have that problem.

> When that does not help and you can't remove a significant number of
> files to shrink the number of used sectors your only chance is to
> extend the FAT drive to some more MB knowing that some of the
> extension will be wasted by bigger clusters so you have to extend
> more.

I was thinking of using Infozip compressed archives.

>> I had to do this originally to split the original 1.2GB Windows C: partition into two 127MB partitions.
>>The cluster size originally was 32K, & afterwards 2048 bytes, which is the smallest for "FAT16>32MB".
>>You'd think that you could get 1024 for<32MB, but it goes back up to 4096.

At least this is default practice for MS-DOS formating partitions < 20M.
If this isn't a bug, then it's planned to be counter-productive - even small 2M paritions have 4096 cluster sizes!

>>I did find a way to hack 1024 into it & allegedly works up to 64MB:
>>http://groups-beta.google.com/group/...a194de0baec44d
>>1) Format a FAT partition (less than 64M).
>>2) Use a disk editor to modify the byte at offset 0D of the boot sector
>> You'll see 04 there, change it to 02. This tells DOS or OS/2 that
>> you want 2 sectors/cluster instead of 4.

But double the entry for "Sectors per FAT" or you might get defective sectors.

>>3) Re-format the partition. When FORMAT reads the Boot sector, it will see
>> a VALID BPB, and will use the values there instead of default values.

I tried this, and it seems to work in MS&PC DOS & OS/2 - ideal for a scratch-pad partition.
I also tried to format a 31M parition as "FAT12<16M" by setting 16 sectors/cluster, and that worked also.

--
"All geneticly engineered foods [even if sourced from Al Qaeda]
are completely safe." - An official statement from the Homeland
Dep't of Food Safety, as made public via NPR on 25 August 2004.