[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Excerpts from Helmut Grohne's message of Mon Dec 05 18:15:53 +0100 2011:
> Hi Michal,
> On Mon, Dec 05, 2011 at 05:03:25PM +0100, Michal Suchanek wrote:
> > Excerpts from Helmut Grohne's message of Mon Dec 05 15:54:19 +0100 2011:
> > > Can we now ignore 2) and concentrate on 1)?
> > 
> > No. If I wanted this semantics I could use shred(1).
> Please report a separate bug about not using fsync then. (or clone this
> bug) They can be fixed independently.
> > I want my files saved.
> Honestly. You seem to have a rather different view on this issue than
> the rest of the world (otherwise it would have been reported way
> earlier).

I would guess that most of "the rest of the world" is not aware of this

It's probably not been like that since day 1 of Linux. I suspect that at
some point Linux implemented some optimization that allows close() to
finish before the space for the written data is even allocated and
others like that which leads to these issues.

> As for me I really do *not* want fsync here. For instance when I use a
> slow usb storage device, I really want cp to finish before the copied
> stuff is written to permanent storage.

Why? Either you want the data on the storage so you eject it and wait
for eject to finish anyway or you are doing something else in the
meantime so you can do so regardless of cp finishing or not.

> So even I would assume that the fsync issue is just wontfix (even though
> I am not the openssh maintainer).
> > Note that this same issue has been found and fixed in dpkg.
> This is good and all. But in general tools simply do not provide fsync
> semantics and people actually expect that now. When firefox tried to
> introduce fsync, it was disabled for performance reasons again. If you
> need it, go sync after you copy. (Or write patches.)

No, it is not good at all that fsync is not used in things like cp.

It was not used in dpkg which led to severe system corruption which is
now fixed but any other tools used to manipulate files should do the
same. Otherwise they are useless.



Reply to: