On Fri, Mar 12, 2010 at 07:56:00PM +0000, Ceri Davies wrote:
> On Fri, Mar 12, 2010 at 08:46:01AM -0600, Mike Gerdts wrote:
> > [...] A better approach would be the equivalent of:
> >
> > 1. ln $file $file.$suffix
> > 2. newfile=$(mktemp $(dirname $file)/$(basename $file).XXXXXX
> > 3. chown $user:$group $newfile
> > 4. chmod $perms $newfile ; # plus more magic to do extended attributes
> > 5. sed $sedprog $file > $newfile
> > 6. rename $newfile $file
>
> It doesn't really qualify as inplace though, does it? Note also that -i
> can optionally leave a backup behind if given a suffix which would
> remove most concerns over trampling files.
If "truly in-place" is not safe, then I don't think we should not have
"truly in-place". Now, is the GNU sed's -i described as "truly
in-place" or is its description able to cover Mike's algorithm? Here's
what the GNU sed manpage says:
--follow-symlinks
follow symlinks when processing in place
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension sup-
plied)
Nothing else is said as to what editing a file "in place" means. I
think that leaves room for an implementor to take Mike's position.
> Note that FreeBSD's sed supports -i (and -I) using an algorithm which
> can potentially fail in the situations that you mention; the manpage
> just calls it out with the following text:
>
> It is not recommended to give a zero-length extension when
> in-place editing files, as you risk corruption or partial content in
> situations where disk space is exhausted, etc.
That is indicative of "truly in-place" editing, but note that the
cautionary note applies to _any_ kind of in-place edit if the filesystem
is COW-based (like ZFS). Some non-extending edits might not complete if
you run out of space and the filesystem is a ZFS dataset, thus leaving
you with corrupted file data.
In other words, I don't think there's any kind of stream edit for which
"in-place" can be safe (see below). I favor Mike's algorithm.
Perhaps we could have a "file contents replace" operation, like
rename(2) but which changes the contents observed through open file
descriptors (and mmap()s) referring to the original... Then you could
get something like in-place edits with safety, plus atomicity as a
bonus. But that'd be a whole 'nother case/project.
Nico
--
