On Sat, Aug 06, 2022 at 08:44:18PM +0100, Ian Jackson wrote: > > The second issue (writing to /dev/full) is indeed fixed in sid / Perl > > 5.34. It was https://github.com/Perl/perl5/issues/6799 and reportedly > > only affects things like character devices (including /dev/full) and > > sockets. I've verified that trying to write to a normal file on a full > > filesystem does set the error() flag on stable / Perl 5.32. > > I wonder what is different about plain files. I suspect the fact that > it "works" (correctly returning errors) for you in this case may be > due to luck (the precise series of calls).
You might want to read the bug then, particularly Tony Cook's comment at https://github.com/Perl/perl5/issues/6799#issuecomment-626511037 Quoting: Perl's I/O objects (that is the IO SV , not PerlIO) can have both an input (PerlIO) file handle and an output file handle. For files that output handle is the same as the input handle [...] For a character device (like /dev/full) or a socket, perl creates a second PerlIO object on the same fd to use as the output handle, and that causes the behaviour this ticket documents. So I don't think luck has anything to do with it. > > Downgrading the severity, but let me know what you think based on the above. > > I still think this is a data loss bug. (Two bugs.) I think it's at most one but whatever. I've just reported https://github.com/Perl/perl5/issues/20060 about the read errors. You might want to do your convincing there if needed :) Obviously it's not going to be fixed on Debian side without upstream involvement, whatever the severity. > > while ( ! eof($fh) ) { > > defined( $_ = readline $fh ) or die "readline failed: $!"; > > ... > > } > > I don't find this particularly convincing. This argument seems to be > saying "never use <> to read lines" which is pretty strange. Surely > it should be possible to use "<>" in its line-reading mode, without > data loss. Yeah, I agree. -- Niko
