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. > to...@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.
