Hello Excerpts from Julien Cristau's message of Sat Dec 25 22:00:11 +0100 2010: > user [email protected] > usertag 607267 squeeze-can-defer > tag 607267 squeeze-ignore > kthxbye > > On Thu, Dec 16, 2010 at 13:40:30 +0100, Michal Suchanek wrote: > > > Package: openssh-client > > Version: 1:5.5p1-5+b1 > > Severity: grave > > File: /usr/bin/scp > > Justification: causes non-serious data loss > > > > > > scp fails to notice close() errors. > > > I'm not sure this is grave, but in any case this won't block the > release, tagging accordingly. >
As data loss is defined as grave I would expect this is the case. I tried on 2.6.36 release kernel (not rc) and the issue stays. I also tried to open and write a file in a scripting shell and found that the error is only reported on fsync(). Not sure if this is compliant to anything but the Linux close(2) man page clearly states: A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.) This suggests that the reason the error is not recognized is due to scp not doing fsync() which is the only guaranteed way to ensure that the data is ever written to the file. This condition may occur when you run out of disk space (which is hopefully rare but the more surprising) and possibly when you run out of disk quota. This same issue also happens with cp(1) from coreutils. Thanks Michal -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
