4 ms·
There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a
by smelbe 4y ago
There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a major source of complexity.
- klodolph 4y agoCould you elaborate? Seems like there’s a bunch of things that can’t be batched together on an ordinary file, without involving symlinks.
- masklinn 4y agoWhat they (and TFA) are saying is that there is no transactional view of the FS. If you could work in “repeatable read” (only and always see the state of the FS before you started the transaction) symlink races wouldn’t be possible.
- rwmj 4y agoI always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg: begin_transaction (); lstat ("/path", ...); lstat ("/path/foo", ...); commit (); In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions. It could also solve the whole thing with ending up with zero-length files because you didn't use the right incantation to update a file atomically on ext4 (https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-a...).
- bhawks 4y agoA general purpose transactional interface widene the error space to include cross process deadlocks / denial of service not to mention performance issues.
- amaranth 4y agoWasn't making userspace handle these kinds of things a big part of "worse is better"?
- masklinn 4y agoTurns out when facing adversarial actors worse is just worse.