Re: save-buffer: avoid data loss on interrupt

[Jim Meyering]

Paul Eggert wrote:
> On 12/13/11 12:52, Jim Meyering wrote:
>> doesn't this deserve to be enabled more often
>> than when someone tweaks the break-hardlink-on-save variable?
>
> I'd like to do that too, but things are a bit tricky here.
> For example, what if the file has a special ACL?
> Won't that get lost?

I can add a test for the presence of an ACL,
and handle that just like a hard link count of 2 or greater:
resort to the standard, non-atomic code path.

>> How about this instead, assuming a file-owner-uid function?
>> (or if the two users of file-attributes is an issue,
>> we could combine file-nlinks and file-owner-uid into
>> a function that calls file-attributes just once)
>>
>> Sure, this might still change the group, but if that's an issue
>> we could compare it to the default group.
>
> Unfortunately one can't predict the ownership of the new file
> so easily.  It might be a setuid directory; on some hosts,
> that causes new files in the directory to have the same
> owner as the directory.
>
> A more reliable way to deal with it might be to create the
> temporary file, and ensure that its owner and group
> and any other special attributes are correct, before copying to it.
> Normally the check should succeed, so this shouldn't cost much
> on the average.  The permissions should be conservative
> (e.g., original permissions sans executable bits) until the
> copying is done.

That sounds good, but complicates the already hairy logic, since
upon mismatch we'd have to clean up and then take the other path.

If the cost of an extra stat is not prohibitive, I'm
tempted to keep this change simple, check for a set-UID
parent directory, and handle that like an ACL.