On Tue, Jan 09, 2024 at 10:57:29AM -0500, Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
>
> I have serious doubts about the "it".
>
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of copying multiple files would be lost because the FAT was
> > filled, and overwritten from the start by files added later in
> > the session.
>
> The FAT doesn't contain file names. It has a fixed size and contains
> one "word" per block in the partition, and that word indicates simply if
> the corresponding block is free or not, and if not, what is the next
> block of the corresponding "file" (where that "file" may be also
> something like a directory).
>
> The FAT doesn't get filled/emptied: it has the same size whether the
> partition is empty or full, because the partition contains a fixed
> number of blocks.
>
> So, I don't doubt you have seen what you have seen, but whatever you
> have seen was not due to "the FAT was filled".
I gues we are talking about VFAT, otherwise the "long" filename doesn't
make much sense.
The LFS layer on top of FAT does have some limitations: "Because the
FAT LFN implementation is layered atop an older, more limited naming
system, there are inevitable complications, such as if an attempt is
made to create too many files with the same first six letters" [1].
Given the baroque construction of that thing (only Microsoft could've
come up with such a monster), I'd not be surprised if there were known
bugs kept around for backward compatibility.
So perhaps what Brad observed was a name collision in the underlying
("bare") FAT file system (I've seen that back then, Windows 3.1) or
some other strange inhabitant of that code biotope.
Cheers
[1] https://en.wikipedia.org/wiki/Long_filename
--
t
Attachment:
signature.asc
Description: PGP signature