On Sat 31 Dec 2016 at 10:35:02 (+0100), to...@tuxteam.de wrote: > On Thu, Dec 29, 2016 at 07:38:18AM +0100, Xen wrote: > > do...@mail.com schreef op 26-12-2016 3:41: > > > > >I encountered this many times on windowz FAT32 in a non-root dir, but > > >never on Linux. I suspect that it was/is one of their "Features". The > > >said "Feature" still was there when using ntfs in XP if I remember > > >correctly. > > > > Perhaps it's just because Windows Explorer doesn't deal well with > > many files. Try to unpack some open source archive of some > > distributor that had to make their sources open, some 1G archive, > > and see how it goes. Not recommended :p. > > > > Then when you've unpacked it, deleting it takes a few years as well. > > So imposing a filesystem limit may just have been a way to ensure > > that their user interface limit is not quickly reached, I don't > > know. > > Calculemus, as Leibnitz said. A bit of experimental informatics: > > dd if=/dev/zero of=dose bs=4096 count=64 > mkfs.vfat dose > sudo mkfs.vfat dose > sudo mount dose /mnt > for i in $(seq 1 10000) ; do sudo touch /mnt/f.$(printf "%05d" $i) || echo > "fail $i" ; done > > The loop starts failing at i == 257 with "no space left on device" > (that's ENOSPC if I remember correctly). The "device" has still > reams of space left: > > tomas@rasputin:~$ df -h > Filesystem Size Used Avail Use% Mounted on > [...] > /dev/loop0 238K 0 238K 0% /mnt > > So 256 must be a limit on number of entries on the top level dir of > FATty file systems (or an implementation limit of Linux's version > of that, but guess whom I trust more to bust that badly). > > Try this at home. Enjoy.
I did, but I had some difficulty replicating your result. I took a USB stick and put a type c partition on it (mkfs.fat doesn't like writing whole devices). Then: # mkfs.fat -i 20161231 -n PETROLEUM2G -r 2000 -v /dev/sdb1 mkfs.fat 3.0.27 (2014-11-12) Auto-selecting FAT32 for large filesystem /dev/sdb1 has 62 heads and 62 sectors per track, hidden sectors 0x0800; logical sector size is 512, using 0xf8 media descriptor, with 3891199 sectors; drive number 0x80; filesystem has 2 32-bit FATs and 8 sectors per cluster. FAT size is 3793 sectors, and provides 485447 clusters. There are 32 reserved sectors. Volume ID is 20161231, volume label PETROLEUM2G. # I now ran your one-liner and created over 20,000 empty files at top level. So I down-sized with: # mkfs.fat -F 16 -i 20161231 -n PETROLEUM2G -r 2000 -v /dev/sdb1 mkfs.fat 3.0.27 (2014-11-12) /dev/sdb1 has 62 heads and 62 sectors per track, hidden sectors 0x0800; logical sector size is 512, using 0xf8 media descriptor, with 3891199 sectors; drive number 0x80; filesystem has 2 16-bit FATs and 64 sectors per cluster. FAT size is 256 sectors, and provides 60789 clusters. There is 1 reserved sector. Root directory contains 2048 slots and uses 128 sectors. Volume ID is 20161231, volume label PETROLEUM2G. # and now at last I could exhaust the top level directory with 1023 entries. As expected, df -h gives /dev/sdb1 1.9G 0 1.9G 0% /media/petroleum2g Like Nicolas I couldn't unpick Gene's rant about the subject as he doesn't seem to distinguish between DOS, the OS, and FAT, the filesystem used by DOS. But I wouldn't expect anyone using DOS seriously to need to have many files in top level directories. If the OP is lucky, the photo frame might create a subdirectory like most cameras/phones etc do, or, like some MP3 players, just display everything it encounters regardless of the subdirectory involved. Cheers, David.