On Fri, 2018-03-16 at 12:39 +0000, Joakim Tjernlund wrote: > > > After reverting the commit, we test 'rm -r', which can remove all > > files, and all seems OK! > > UHH, this is mine (and Davids work from 2007)! > I cannot remember any details this long afterwards but I guess you cannot > just > revert that part as it triggers some other bug, David?
Right, the issue was with f_pos in the directory. The 'rm' we were testing with at the time would delete a bunch of directory entries, then continue with its readdir() to work out what else to delete. But when we were handling f_pos on directories merely as the position on the list, and when we were *deleting* things from that list as we went, some dirents ended up moving so that they were *before* the position that 'rm' had got to with its readdir(). But... the list we're traversing is *already* ordered by CRC, and that could be a much saner thing to use as f_pos. We just have to make sure we cope with hash collisions. Shifting left by 4 bits and using the low 4 bits would allow us to cope with 16 names with the same hash... but I'm not sure that's good enough.
smime.p7s
Description: S/MIME cryptographic signature
