3 ms·
If the checksums collide, then the number after the tilde is incremented again, (eg. SOBC84~2.ASP). This time, it won't stop at ~4, so you can go up to ~10 and
by Quackmatic 11y ago
If the checksums collide, then the number after the tilde is incremented again, (eg. SOBC84~2.ASP). This time, it won't stop at ~4, so you can go up to ~10 and beyond. The file name will be shortened accordingly to fit the number in (eg. SOBC8~10.ASP). This was tested on Windows 7 x64.
- deleted 11y ago[deleted]
- netsec_burn 11y agoAnd now the last question, how far can you take that logic? What happens at 1,000,000 (one million file names generated) when there are no more characters left to remove from the left side? Segmentation fault?
- Quackmatic 11y agoThat's worth trying. Inducing a bug in kernel code could be interesting.
- albinoloverats 11y agoCan FAT support that many files in a single directory?
- netsec_burn 11y agoActually, 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.
- Quackmatic 11y agoI'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-collisions https://usn.pw/blog/gen/2015/06/09/filenames/#follow-on-coll...
- userbinator 11y agoA 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.