On Thu, Dec 29, 2016 at 07:38:18AM +0100, Xen wrote:
doark@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.