On Tue, Aug 20, 2019 at 05:04:39PM +0200, Karel Zak wrote: > On Tue, Aug 20, 2019 at 03:17:42PM +0200, Patrick Steinhardt wrote: > > That being said, if we agree on a proper fix here then I'd be > > happy to post a v2. > > Go ahead. Note that Bernhard Voelker sent me (off list, but thanks;-) another to link the original coreutils discussion: https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00156.html where is something about close() and dup(). My note: It seems there is no ideal solution which is portable and reliable on all platforms (kernels). The current solution with std{out,err} close is also not elegant as the close makes it useless with things like ASAN or another built-in debuggers, and it's incompatible with some libc. The question is what does it mean for util-linux. I don't think we need 100% reliability on all platforms; the primary target is Linux, commonly used filesystems, standard use-cases and code (=!behavior) portability -- everything else is bonus. From this point of view dup()+close() sounds like better than the current solution. >From my point of view all this game with the streams is just a way how to detect some basic users' mistakes. I don't think we can detect serious I/O errors without fsync(), and close() itself does not guarantee anything. So, it does not make sense trying to make it super durable, reliable and portable to all operation systems if at the end you rely on poor close() ... Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com
