said:
>
> >Are you sure about this. When I reboot after a dirty shutdown (as far as
> >driver D: is concerned), I don't get a chkdsk on D: until the call
> >statement. I know because chkdsk D: would fail otherwise. Also, because
> >of the call, I see the output text and only real activity after a dirty
> >shutdown.
>
> I'm pretty sure about this. If would be very complicated for HPFS.IFS to
> know that there is a call the chkdsk elsewhere in config.sys. If the
> autocheck option calls out drive D: it is going to get chkdsk'd via the
> IFS.
I guess not so much that it is complicated for HPFS.IFS to know the chkdsk call
elsewhere but that it tries in both locations but fails when invoked at the IFS.
When I only had the autocheck on D: at the IFS, after a dirty shutdown, it would
check C:, succeed, proceed to D: and subsequently fail with a not enough memory
message, and continue to boot. Many file operations could not be completed
because of the uncleared dirty shutdown flag. That's when I stumbled onto the
fix in the FixPak readme.
> If I understood your description of your config.sys, you have:
>
> IFS=C:\OS2\HPFS.IFS ... /AUTOCHECK:CD
> DEVICE=C:\OS2BOOT\CHKDSK.SYS
> CALL=C:\OS2\CHKDSK.COM D: /C
Essentially correct.
> The way this works is nothing gets chkdsk'd unless there is a dirty
> shutdown. If there is a dirty shutdown, the autocheck invokes chkdsk for
> C: and D: and then forces a reboot. The call the chkdsk.com never gets
> executed.
This is still somewhat counter to my experience. Dirty shutdowns did seem to
prompt the call to chkdsk.com in the "CALL" line. I could witness the
"Searching for lost data" after the call (some text is produced at every reboot
after the "CALL" statement, "Searching for lost data" only appears after a dirty
shutdown). The IFS invoked chkdsk has failed in the past because of
insufficient memory.
> After the reboot, the autocheck does nothing because the drives
> are not dirty. The chkdsk.com runs but bypasses the chkdsk logic because
> it was invoked with the /C option and the drive is not dirty.
Again, somewhat different than what I've seen. I'll do some experimenting at
some point (a little lower in the priority queue of course) and see if I can
verify what I am suggesting. The amusing thing is that I've finally gotten to
the point where everything is fairly reliable and have not had a dirty shutdown
in awhile. It's long enough ago that I've got to prompt the event because it'll
be a long time before it will come naturally.
> What should work, and should save a reboot is:
>
> IFS=C:\OS2\HPFS.IFS ... /AUTOCHECK:C
> CALL=C:\OS2\CHKDSK.COM D: /C
>
> The caveat is that everything called for by config.sys, directly and
> indirectly, must come from the C: drive until after the call to
> chkdsk.com. In some setups, this might not be possible, so the chkdsk.sys
> method is the only viable alternative.
This would work for me. I'll probably move to this after my little experiments.
> As I said, I have not tested this, but I would be surprised if were
> otherwise.
I'll report back as soon as I find out.
> Steven
-Rocky
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 03 |
February |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
