Solutions for Blue Screen of Sudden Death? - OS2

This is a discussion on Solutions for Blue Screen of Sudden Death? - OS2 ; 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Solutions for Blue Screen of Sudden Death?

  1. Solutions for Blue Screen of Sudden Death?


    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?

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


  2. Re: Solutions for Blue Screen of Sudden Death?

    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

  3. Re: Solutions for Blue Screen of Sudden Death?

    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!

  4. Re: Solutions for Blue Screen of Sudden Death?


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


  5. Re: Solutions for Blue Screen of Sudden Death?


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


  6. Re: Solutions for Blue Screen of Sudden Death?

    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

  7. Re: Solutions for Blue Screen of Sudden Death?


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


  8. Re: Solutions for Blue Screen of Sudden Death?

    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

  9. Re: Solutions for Blue Screen of Sudden Death?


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


  10. Re: Solutions for Blue Screen of Sudden Death?

    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!

  11. Re: Solutions for Blue Screen of Sudden Death?


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


  12. Re: Solutions for Blue Screen of Sudden Death?

    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!

  13. Re: Solutions for Blue Screen of Sudden Death?

    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.

  14. Re: Solutions for Blue Screen of Sudden Death?


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


  15. Re: Solutions for Blue Screen of Sudden Death?

    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!

  16. Re: Solutions for Blue Screen of Sudden Death?

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



  17. Re: Solutions for Blue Screen of Sudden Death?


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


+ Reply to Thread