Package: coreutils
Version: 5.2.1-2
Severity: wishlist
Tags: upstream
Please add an --atomic option, which would make install create a
temporary file in destination directory, copy the data into it,
chmod/chown it as appropriate and then rename() to destination name.
This obviously should not be the default, since the destination
directory is not guaranteed to be writable.
Current behavior may cause problems when other program tries to open
the file while it is being installed. It does for me, I use install to
update a blacklist from a cronjob, and exim sometimes tries to open the
file before it is chmod-ed, causing deferrals.
regards,
Marcin
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Versions of packages coreutils depends on:
ii libacl1 2.2.29-1.0.1 Access control list shared library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
coreutils recommends no packages.
-- no debconf information
This would be a good feature to have, it's a pity that the internal copy()
function in coreutils doesn't support this.
Probably the first step towards this goal would be to look at how to have cp,
mv, etc all take advantage of copying to a temporary file that would be
synchronised with fsync() before being renamed. Also it would be good to
have an option to call fsync() before close(). Sometimes you merely want to
know that the data is committed to disk before the program returns.
Russell Coker <[email protected]> wrote:
> This would be a good feature to have, it's a pity that the internal copy()
> function in coreutils doesn't support this.
>
> Probably the first step towards this goal would be to look at how to have cp,
> mv, etc all take advantage of copying to a temporary file that would be
> synchronised with fsync() before being renamed. Also it would be good to
> have an option to call fsync() before close(). Sometimes you merely want to
> know that the data is committed to disk before the program returns.
These do sound like nice additions.
It's probably going overboard, but some application might
even want to call fsync on each containing directory.
On Wednesday 27 June 2007 23:39, Jim Meyering <[email protected]> wrote:
> It's probably going overboard, but some application might
> even want to call fsync on each containing directory.
I expect that the overhead of calling fsync on the directory is negligible
compared to the overhead of calling it on the files. So it might be best to
just have a single option.
Russell Coker <[email protected]> wrote:
> Probably the first step towards this goal would be to look at how to have cp,
> mv, etc all take advantage of copying to a temporary file that would be
> synchronised with fsync() before being renamed. Also it would be good to
> have an option to call fsync() before close(). Sometimes you merely want to
> know that the data is committed to disk before the program returns.
These both sound like nice additions, but I'd guess the fsync option
should be independent from the tempfile+rename option. The original
request was only about tempfile+rename.
My vague impression is that fsync will make things run considerably
slower on many implementations, and it won't help the original
requester at all. tempfile+rename fixes the problem that the original
request was about. Probably part of the confusion here is due to the
choice of the name "--atomic" to mean tempfile+rename; in some sense
rename is atomic, but it's not the same sense that fsync is.
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.