4 ms·
tbf this is a really common pitfall and arguably a design mistake in Linux/POSIX, opening files should be a straightforward operation without pitfalls. Even est
by PhilipRoman 2y ago
tbf this is a really common pitfall and arguably a design mistake in Linux/POSIX, opening files should be a straightforward operation without pitfalls. Even established programs mess this up all the time, see https://github.com/systemd/systemd/issues/30690 https://github.com/systemd/systemd/issues/30690 and https://github.com/magic-wormhole/magic-wormhole/issues/363 https://github.com/magic-wormhole/magic-wormhole/issues/363
- blueflow 2y agoThis is by design and a obvious implication from the inode structure. Bash, for example, relies on that for process substitution. On the other side, systemd-tmpfiles used to recurse into '..' when unlinking, wiping your system. So i'm not surprised they didn't get the open() calls right.
- PhilipRoman 2y ago>obvious implication from the inode structure I don't quite follow. In fact, at least on Linux, opening a FIFO with O_RDWR (which POSIX leaves undefined) will not block so it can work. IMO blocking for opening as writable can be justified, but I don't see why opening for readonly has to. I'm sure there is some justification for it like SIGFPE or distinguishing empty data from no data, but the result still seems fishy. >systemd-tmpfiles used to recurse into '..' when unlinking ok this one is just hilarious
- oguz-ismail 2y ago> I don't see why opening for readonly has to. If it didn't you'd have no way of telling if there's anyone at the write end of the pipe. Isn't it obvious?