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".


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue 09 Jan 2024 at 10:57:29 (-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 would agree with that. I don't follow the evolution of FAT,
but what seems most likely is that the root directory filled up.
The size of that is fixed when formatted, at least up to FAT16.
Long filenames will eat it up more quickly still. Create
subdirectories and the problem goes away.

With large sticks nowadays, the problem revolves more around the
/time/ it takes to read huge subdirectories. I don't know what
the limitations on FAT32 root directory sizes are.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZZ1/AAAKCRAFyCz1etHa RjyVAJ49JaNm2UIQbr4i6SB/LGnkU56KrACdGryExCXXacOygCBDVszziH9oHVw=
=BDQG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Wright [2024-01-09 10:07:26] wrote:

but what seems most likely is that the root directory filled up.
The size of that is fixed when formatted, at least up to FAT16.
Long filenames will eat it up more quickly still.

Long file names are actually kept in a (hidden) files, so they don't eat
up the directory space any more than normal file names.
(I'm talking about VFAT, here, which is the standard way to add long
file names to FAT)

tomas@tuxteam.de [2024-01-09 18:14:47] wrote:

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].

So indeed if you have too many names in the same directory you're likely
to bump into problems (you'd hope it would signal an error rather than
silent corruption, but ...).

Of course, it's usually easy to work around the problem by spreading the
files within several directory. For ripped CDs, I'd recommend one
directory per CD (I use 2 levels: every artist gets a directory and in
that directory every album gets its own subdirectory).


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue 09 Jan 2024 at 15:30:49 (-0500), Stefan Monnier wrote:

David Wright [2024-01-09 10:07:26] wrote:

but what seems most likely is that the root directory filled up.
The size of that is fixed when formatted, at least up to FAT16.
Long filenames will eat it up more quickly still.

Long file names are actually kept in a (hidden) files, so they don't eat
up the directory space any more than normal file names.
(I'm talking about VFAT, here, which is the standard way to add long
file names to FAT)

(I find the term "vfat" rather ambiguous.) Here is the output from
a USB stick that I used on Boxing Day to pass a copy of a Christmas
Day video (a flaming pudding) to a Windows computer.

$ grep _FS_ /run/udev/data/b8\:17
E:ID_FS_LABEL=china256
E:ID_FS_LABEL_ENC=china256
E:ID_FS_UUID=F8FA-4A08
E:ID_FS_UUID_ENC=F8FA-4A08
E:ID_FS_VERSION=FAT16
E:ID_FS_TYPE=vfat
E:ID_FS_USAGE=filesystem
$

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 246 MiB, 257949696 bytes, 503808 sectors
Disk model: DataTraveler 2.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xefc20858

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 63 503807 503745 246M e W95 FAT16 (LBA)
$

$ ls -lR /media/china256/
/media/china256/:
total 78488
-rw-r----- 1 auser auser 80357062 Dec 25 18:35 Looong-Filename.LOONG-EXT
drwxr-x--- 2 auser auser 8192 Dec 26 10:18 'System Volume Information'

'/media/china256/System Volume Information':
total 16
-rw-r----- 1 auser auser 76 Dec 26 10:18 IndexerVolumeGuid
-rw-r----- 1 auser auser 12 Dec 26 10:18 WPSettings.dat
$

The windows computer vomited those Boxing Day entries onto the stick.
Here's the pertinent bit:

# hexdump -C /dev/sdb | grep -B2 -A14 -m1 china256
0001c2b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00026c00 63 68 69 6e 61 32 35 36 20 20 20 08 00 00 00 00 |china256 .....|
00026c10 00 00 00 00 00 00 c7 00 af 4e 00 00 00 00 00 00 |.........N......|
00026c20 42 6d 00 65 00 2e 00 4c 00 4f 00 0f 00 0e 4f 00 |Bm.e...L.O....O.|
00026c30 4e 00 47 00 2d 00 45 00 58 00 00 00 54 00 00 00 |N.G.-.E.X...T...|
00026c40 01 4c 00 6f 00 6f 00 6f 00 6e 00 0f 00 0e 67 00 |.L.o.o.o.n....g.|
00026c50 2d 00 46 00 69 00 6c 00 65 00 00 00 6e 00 61 00 |-.F.i.l.e...n.a.|
00026c60 4c 4f 4f 4f 4e 47 7e 31 4c 4f 4f 20 00 14 ef ae |LOOONG~1LOO ....|
00026c70 29 58 9a 57 00 00 7c 04 9a 57 03 00 c6 26 ca 04 |)X.W..|..W...&..|
00026c80 42 20 00 49 00 6e 00 66 00 6f 00 0f 00 72 72 00 |B .I.n.f.o...rr.|
00026c90 6d 00 61 00 74 00 69 00 6f 00 00 00 6e 00 00 00 |m.a.t.i.o...n...|
00026ca0 01 53 00 79 00 73 00 74 00 65 00 0f 00 72 6d 00 |.S.y.s.t.e...rm.|
00026cb0 20 00 56 00 6f 00 6c 00 75 00 00 00 6d 00 65 00 | .V.o.l.u...m.e.|
00026cc0 53 59 53 54 45 4d 7e 31 20 20 20 16 00 9e 4a 82 |SYSTEM~1 ...J.|
00026cd0 9a 57 9a 57 00 00 4b 82 9a 57 02 00 00 00 00 00 |.W.W..K..W......|
00026ce0 e5 46 55 50 44 4f 7e 31 44 45 42 20 00 50 04 9e |.FUPDO~1DEB .P..|
#

As you can see, the LOOONG~1LOO entry is preceded by two extra entries
(in reverse order) containing a UCS-2 version of Looong-Filename.LOONG-EXT, mixed in with various other bytes.

The System Volume Information follows in the same way, and then the
start of what looks like a deleted .deb entry, probably ifupdown.

tomas@tuxteam.de [2024-01-09 18:14:47] wrote:

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].

So indeed if you have too many names in the same directory you're likely
to bump into problems (you'd hope it would signal an error rather than
silent corruption, but ...).

Whether you run out of directory entries or unique filenames first
will depend on the use case. The normal limit for the top-level
FAT directory is 512 entries, and I've just checked this by touching
505 empty files (names are A<4 digits>) in the directory above.
Adding two 3-entry filenames and the compatibility volume label
makes 512 entries.

OTOH, there can be ~100 filenames that start with the same five
characters, so storing all your Bach cantatas as CantataBWV1,
CantataBWV2, etc would presumably fail.

Of course, it's usually easy to work around the problem by spreading the files within several directory. For ripped CDs, I'd recommend one
directory per CD (I use 2 levels: every artist gets a directory and in
that directory every album gets its own subdirectory).

Our car can certainly handle subdirectories: currently our "car stick"
has 1421 .m4a files in 60 subdirectories. (OTOH it gets screwed up by
the U3 USB stick that we somehow came by.) But it's no guarantee that
every device can handle them, particularly those of a certain age.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)