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

[Lex Trotman]

On 6 November 2010 20:33, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On Fri, 05 Nov 2010 23:08:57 +0100
> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>
>> Le 05/11/2010 21:33, Dimitar Zhekov a ecrit :
>> > On Fri, 05 Nov 2010 19:50:59 +0100
>> >
>> > 1. Open the file for reading and writing.

I'm not sure all non-local filesystems support read/write or they
support it via local caching which isn't safe until flushed to the
remote system

>> > 2. If the new data is longer, append the extra part only (thus claiming
>> > the required disk space).

A remote filesystem might not allocate it on the remote system only on
the local cache until the file is closed.

>> > If that fails, truncate to the original size and abort.
>> > 3. Write the data (without the extra part, if any).

This requires a seekable filesystem, again not sure all remote systems
support it.

>> > 4. If the new data is shorter, truncate.
>> >
>> > That's almost 100% safe (there is no apparent reason for truncate to a
>> > smaller size to fail), preserves everything, no extra disk space, not
>> > even extra I/O.
>>
>> Even if it seems really interesting, I'm not sure it is really reliable.
>> What if the program terminates (power loss, whatever) during the final
>> write? What if a network connection is broken before we truncate?
>
> In any given moment, the file is either OK, or it contains the old data
> followed by garbade. The latter should be reported to the user.

Again its not ok if it only exists in the local cache and the write
back to the remote fs is interrupted.

>
>> Since the whole operation is not atomic, it's not 100% safe, and I still
>> believe that the backup is needed.
>> This said, it could be a good implementation for non-safe file saving,
>> that would be safer than without.
>
> Of course, I propose this only for use_safe_file_saving = FALSE.

Its advantage is minimal transfers and no extra space in the no backup
case, but doesn't happen with the backup case, the transfers are the
same as just writing the file and so is the disk space.

So if you are feeling really lucky and want to use unsafe saving and
no backup and the filesystem supports it then its an advantage.

The problem is that on local filesystems where its safe is where you
don't need the performance and on remote filesystems where you need
the performance you also need the safety.  Can't win.

>
>> But that's probably much work for less gain IMHO.
>
> I'll write a non-GIO variant first, as a proof of concept. The current
> non-GIO is buggy anyway. First:
>
> if (G_UNLIKELY(len != bytes_written))
>        err = errno;
>
> but fwrite() is not guaranteed to set errno, only write() is.

Even write's behavoir is filesystem dependent IIUC.

>
> Second, and more important, the result of fclose() is not checked, for
> a buffered file stream. On lack of disk space, on my system fwrite()
> happily returns written == len, but fclose() fails. YMMV.
>
> If not anything else, we should use non-buffered I/O, with fsync(), and
> check the result of close() anyway.

Yes.

Cheers
Lex

>
> --
> E-gards: Jimmy
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>