Can I suggest, that while this topic is interesting, and should be
pursued, the question of how to implement in-place editing is not
relevant to *this* case, since it doesn't propose to offer it at this
time. Note that this case does not replace /usr/gnu/bin/sed.
(The idea to do so at a future time, in a future case, is probably still
a good one. But needn't be done thought about right now.)
- Garrett
On 03/12/10 01:39 PM, Nicolas Williams wrote:
> 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
>
