Re:A Tale of Two File Names: deconstructing the checksum in ...
by albinoloverats on Wednesday June 10, 2015 @09:40AM
(#9692052)
Can FAT support that many files in a single directory?
Re:A Tale of Two File Names: deconstructing the checksum in ...
by userbinator on Wednesday June 10, 2015 @09:57AM
(#9692175)
A directory is stored as a linked list of clusters like regular files, and the 32-bit filesize field is irrelevant for a directory, so it theoretically could be as big as the whole volume - just keep adding clusters to the chain.
Filesystem drivers may give up long before then, and access to such a huge directory would be very slow, but there's nothing in the filesystem structures itself that would prevent it. I've written FAT code for an embedded device that I can confidently say would have no problems with large directories, since it'll just keep following the cluster chain to the end.
Re:A Tale of Two File Names: deconstructing the checksum in ...
by netsec_burn on Wednesday June 10, 2015 @09:44AM
(#9692085)
Actually, it doesn't look like it. It might need to be a race condition done with a program (delete the old files to keep it going to a million). Might be tricky.
Re:A Tale of Two File Names: deconstructing the checksum in ...
by Quackmatic on Wednesday June 10, 2015 @03:26PM
(#9694683)
I've tried it. It works (this is on NTFS) and the end result is a little anticlimactic: https://usn.pw/blog/gen/2015/06/09/filenames/#follow-on-coll...
Re:A Tale of Two File Names: deconstructing the checksum in ...
by Quackmatic on Wednesday June 10, 2015 @09:33AM
(#9691987)
That's worth trying. Inducing a bug in kernel code could be interesting.
Segmentation fault?