[Geany-devel] Changed file saving implementation for systems with GIO

[Colomban Wendling]

Le 05/11/2010 20:08, Dimitar Zhekov a écrit :
> On Thu, 04 Nov 2010 23:37:28 +0100
> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> 
>> Le 04/11/2010 21:42, Dimitar Zhekov a ecrit :
>>>
>>> For more than 20 years now, the only safe save is to write the data
>>> into a temporary file in the same directory, and then rename it over
>>> the target file. Even if the rename fails, you still have the temporary
>>> file. That changes the onwership and permissions, which is exactly the
>>> behaviour of the safe g_file_set_contents().
>> Well... stop me if I'm saying bullshit but what about:
> 
> No, you are not; I should have been more specific. It's the only way
> which requires 2x disk space (that is unavoidable) but not 2x I/O. For
> Geany the latter doesn't matter so much, but glib is a general purpose
> library, and that's why it includes a safe method that modifies the
> metadata and links, and an unsafe method (documented as "the safest way
> possible", no less!), which preserves them.
> 
> Our choices are:
> 
> 1. The unsafe old or GIO method. Already supported.
> 2. The safe glib method which modifies the metadata/links. Supported
> for GIO = false, easy to include for GIO = true.
> 3. Our own method, which is safe, but generates 2x the I/O (minimum).
> 4. Our own method, based on the safe glib method, which preserves at
> least the ownership and permissions (but even that fails sometimes).
> 
>> backup = path + '~' # or whatever
>> if copy (path, backup_path): # COPY file to the backup
>>   if not write (path, data): # write in original file
>>     move (backup_path, path) # if write failed, restore backup
>>   elif not make_backup:
>>     unlink (backup_path) # if no backup is to be done, delete backup
> 
> That'll be fine if backups are on, but as Lex pointed out, does too much
> I/O if they are off. So for backups = false we can:
> 
> a. Create filename-foo, write data to it, abort and unlink on failure.
> b. Write data to filename. On failure, rename filename-foo to filename,
> and notify the user that the metadata and links are lost.
> c. If even the rename fails, which is highly unlikely for files in the
> same directory, inform the user that the original file is _probably_
> lost, and if so, filename-foo contains the data, but lacks the
> metadata and links.
Hey, that's quite clever :) We would then avoid to have to read the
original file.
However if the original file size is less than half the new data, the IO
are worst [1]... but I think that this is not relevant for a text editor.

[1] assuming read and write has the same cost. No idea if it is likely
to be true or not.

> (probably, because remote filesystems may do the rename but fail to
> report it; that's specially mentioned for NFS in rename(2):BUGS)
Ouch. If we can't even trust the FS, what to trust? So I guess, "let's
hope it'll work".

> (filename-foo and not filename~, because we don't our insurance file
> containing the _new_ data to be replaced by some accidential backup, be
> it Geany's (if the user subsequently turned backups on) or cp's, mv's
> etc.)
> 
>> The problems I see are:
>>  1) needs at least 2 times the size of the file in the target directory
>>     (but it's the same anytime we bake backups)
> 
> Unavoidable.
> 
>>  2) backup file may have altered permissions/attrs
> 
> ...links, ACL-s etc. Unavoidable.
> 
>>  3) ...so if write fails, we have changed the permissions/attrs on the
>>     original file
> 
> Unavoidable.
> 
>> In the worst case, the original file has another name and lost its
>> permissions/attrs.
> 
> Unavoidable. Alas, no miracles for us.
So this solution seems quite interesting :)

> Being a bit lazy, I'd prefer to include the safe glib method in the GIO
> code path (with the use_safe_file_saving option, as before) and be
> done with it. So for limited disk space and/or unstable connections,
> just turn the option on, we even have a GUI for that now. It's a
> compromise, but what isn't?..
I'm tempted to be of your opinion -- but as already said in another
mail, I'm not really concerned as far as local files got saved correctly.


Regards,
Colomban