> Ok, I've been following this thread for awhile, and I think I missed the
> first email, but I don't get something: Why do we need to store the 8.3
> version in a backup? It's a pretty simply algorithm to get the 8.3
> filename from the LFN one, why not put the 8.3 version back when you
> restore to the vfat partition, and completely hide the 8.3 filename?
Because if I have two files in a directory:
My Stupidly-named Big List (A-K).lst My Stu~1.lst
My Stupidly-named Big List (L-Z).lst My Stu~2.lst
The back-up program throws away the short names, and backs them up. Now,
when it comes to restore them, which file will it restore first? If it
restores "My Stupidly-named Big List (L-Z).lst" first, for whatever reason,
that will have the short name "My Stu~2.lst".
Even better, say I actually had a file called "My Stu~1.lst", and the above
files were ..~2 and ..~3 respectively. Now if one of the long named files
gets restored first, it becomes ..~1. So we can't restore "My Stu~1.lst" at
all, because it only has a short name.
The original message (I think) pointed out that some brain-dead 32bit Win
apps store the short, not the long name. So in the above situation, they'll
suddenly be referring to the wrong file. Presumably 16bit apps suffer from
this all the time, but that's their tough luck.
Anyone fancy just removing fatfs support from the kernel altogether, and
doing it in user space using userfs / podfuk? ;-) After all, nobody actually
stores live data on a *fatfs and uses it from Linux, right? <g>
-- Never count your chickens before they rip your lips off- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/