Bug#607267: /usr/bin/scp: fails to notice close() errors

[Michal Suchanek <michal.suchanek@ruk.cuni.cz>]

Hello

Excerpts from Julien Cristau's message of Sat Dec 25 22:00:11 +0100 2010:
> user release.debian.org@packages.debian.org
> 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