# 2026-08-04 - Re: DOS on USB key bit me
       
       Responding to Anna's post about DOS [1]:
       
       > My kindergarten-age kid got really into keeping a
       > daily diary, using SvarDOS's native editor.
       >
       > Well, sadly, I didn't back up her diary or my to-do
       > list. Evy unplugged the netbook it was running on,
       > which has no battery, and most of the filesystem,
       > including the docs folder where those textfiles
       > lived, became corrupted and unreadable.
       >
       > I wish I knew how to try to recover corrupted files
       > and folders from DOS on a USB stick. I wonder if I'm
       > the only person in the world with this problem?
       
       I don't run DOS from a USB key, so i don't have this problem, but i
       do have a few thoughts.  By default SvarDOS uses a synchronous
       filesystem without disk cache.  So i am guessing the power was pulled
       while the editor was running and still had a file open.  The classic
       solution is backups & restores.
       
       To recover the corrupted data, i would probably plug the USB key into
       a Linux box, use the `dd` command to get an image, and then use the
       `strings` command to rip the text content out of that image.  Then
       i'd search for known text.  With luck, FAT fragmentation won't be too
       bad, and recovering some data might be possible.
       
       I like the idea of having multiple partitions on the USB key.  That
       would enable a backup strategy.  A belt & suspenders approach might
       also involve duct-taping the power plug to the netbook to prevent
       unplugging it while it's powered on.  Also, plugging the adapter into
       a battery-backed UPS.
       
       p.s.
       
       I've experienced other fun ways to corrupt FAT filesystems.
       
       The dev86 BCC compiler defaults to passing (int) arguments, but
       the fseek() libc function takes a (long int) argument for the file
       offset.  So calling fseek(fp, 0, SEEK_END) will fill in random
       data for the missing bits, producing an absurdly large file offset,
       and risking FAT corruption on subsequent writes.  Calling
       fseek(fp, 0L, SEEK_END) will work as intended.
       
       The DJGPP GAWK system() command will run a child program.  If GAWK
       has any open files, and if the child program writes to any temporary
       files, then that child program will re-use existing file handles that
       GAWK already had open, and then close them on exit.  This works fine,
       but after control returns to GAWK, if GAWK tries to write to those
       now-invalid file handles, it will result in FAT corruption.
       
       Modern computer users expect security and stability guarantees that
       DOS makes no promises about.  On top of that, modern Internet users
       expect automatic backups and plug-and-play hardware.  Those
       expectations will need to be managed when substituting offline-only
       retrocomputing technology.
       
       p.p.s
       
       Anna recovered the data. [2]
       
       tags: community,retrocomputing,technical
       
       # Footnotes
       
 (TXT) [1] DOS on USB key bit me
       
 (TXT) [2] I recovered the diary
       
       # Tags
       
 (DIR) community
 (DIR) retrocomputing
 (DIR) technical