Bug 414451 - mv should call fsync() on copied file before unlinking original
mv should call fsync() on copied file before unlinking original
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Ondrej Vasik
Depends On:
  Show dependency treegraph
Reported: 2007-12-06 12:37 EST by Jeff Layton
Modified: 2014-06-18 03:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-16 07:16:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Layton 2007-12-06 12:37:30 EST
Opening this as a RHEL5.1 bug, but it's actually an upstream problem as well...

This was brought to my attention as a result of working on bug 329431. In that
case, CIFS had a bug where write failures were not being properly reported at
fsync or close, and this was causing mv to think that it had successfully copied
the file. It would then delete the original even though the new file wasn't
successfully written out.

While fixing mv wouldn't have worked around that bug, mv should be doing a fsync
on the new file that it writes out before closing it to ensure that it has
actually been committed to the device. It appears to check the return val on
close(), but that's not always reliable. From close(2) manpage:

       A successful close does not guarantee that the data has  been  success-
       fully saved to disk, as the kernel defers writes.  It is not common for
       a filesystem 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.)

It seems like it would be safest to have mv call an explicit fsync() when
copying a file to make sure that it has actually been written out.
Comment 1 Jim Meyering 2008-03-11 06:16:43 EDT
Hi Jeff,

Thanks for the suggestion.
imho, mv/cp should not call fsync before close by default.  However, if you
think of this as a feature request, you're not the first.  Adding --atomic or
--fsync-before-close options (two separate things) to programs like mv and cp
might be worth doing.  This has been brought up before.  See the discussion here
or the Debian bug that prompted the thread: http://bugs.debian.org/322457

Regarding close not reporting write failure, that's true, and it would be safer
always to call fsync when mv has to resort to copying (rather than the usual
rename), but you would not like the performance impact.  Calling fsync or
fdatasync is like applying a very big hammer (think cartoon-sized ;-), and is
rarely appropriate.  If with CIFS, one cannot rely on close to detect the usual
ENOSPC-style errors, then *many* applications will end up misbehaving...

If you're interested in pursuing the option-adding idea, please raise the issue
upstream, on bug-coreutils@gnu.org.
Comment 2 RHEL Product and Program Management 2008-06-02 16:27:03 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 4 RHEL Product and Program Management 2008-06-16 07:16:45 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

Note You need to log in before you can comment on or make changes to this bug.