-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Dec 29, 2016 at 07:38:18AM +0100, Xen wrote: > [email protected] 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. - -- t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlhne8YACgkQBcgs9XrR2kYR9wCfdvZnntfbmoIbE1Q5LWZxLOh7 pF0An3BJbsyaWpwOEpWYNZ4xPfVQfgX2 =I4nJ -----END PGP SIGNATURE-----
