[nflug] fsck versus chkdsk

[wpos2 at adelphia.net]

This is the beginning of the new thread I promised several minutes ago.

In the computer lab, people often come in with floppy disks.  (I just 
realized that this may be a soultion to the rebooting problem in favor 
of thumb drives.  But read on.)  The problem I'm talking about seems to 
happen consistently with floppies whose origin is from a Windows 9x 
machine (some of which are still on campus).  They put the floppy in the 
Lab machine (which runs Windows XP), and I don't remember off hand if 
they're able to read the floppy at this point.  Anyway, at some point 
between inserting the floppy and trying to save a file (preexisting or 
otherwise), the floppy craps out. Chkdsking will usually result in 
something like "Read 0 bytes at sector x," and at this point it doesn't 
seem that anything can be done with XP. (I never use the GUI chkdsk, 
because it never gives a report of what it found.)  Parenthetically, 
there used to be a 98 machine at the Lab, and running a thorough 
scandisk (after several minutes) seems to put things in order.  I know 
that XP is not quite the avatar of backwards compatibility, and the 
scuttlebut is that XP writes floppy FATs differently than 9x, and mixing 
one FAT writing process with another scrambles it.

I usually have my dual-boot laptop with me at work.  (Guess which OS I 
boot into regularly.)  Fscking here usually results with something like 
"read x bytes instead of y bytes at sector z."  However, I am able to 
mount the floppy (after a "input/output error message) enough to copy 
the contents to a thumb drive.  (My machine doesn't reboot spontaneously 
like the others, but I digress.)  Then I'm able to reformat the floppy 
under XP, CAREFULLY insert the thumb drive into that machine, copy the 
disk's former contents, and we're in business again.

So, finally, here's my question: are there any Linux commands or 
utilities that are more effective in this case than fsck.vfat?  I 
usually use the parameters afltvVw, but it seems that any parameters 
that I use (including no parameters) have the exact same result, except 
of course for v.  For quick reference:
usage: fsck.vfat [-aAflrtvVwy] [-d path -d ...] [-u path -u ...]
                device
   -a       automatically repair the file system
   -A       toggle Atari file system format
   -d path  drop that file
   -f       salvage unused chains to files
   -l       list path names
   -r       interactively repair the file system
   -t       test for bad clusters
   -u path  try to undelete that (non-directory) file
   -v       verbose mode
   -V       perform a verification pass
   -w       write changes to disk immediately
   -y       same as -a, for compat with other *fsck

I suppose I've found a solution in copying the floppy contents back 
after reformatting, but I'm just miffed that a relatively proprietary 
dinosaur can do what Linux can't.  Or is this a symptom of Trade Secret 
Syndrome?

Any insight will at least give me peace of mind, for which I will be 
grateful.
_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug