signal to release an fd?

Stef Bon stefbon at gmail.com
Sun May 22 01:38:54 PDT 2011


2011/5/22 Liam R E Quin <liam at w3.org>:
> On Sat, 2011-05-21 at 21:03 +0200, Stef Bon wrote:
>
>> According to me keeping a file open is not strange and should not be
>> fixed. You need a filedescriptor to set a lock.
>
> But you don't necessarily need an exclusive lock. One atomic strategy
> for file->save is to save to a temporary file and then rename at the
> last moment.
>
> There's no standard signal, although maybe inotify and/or gamin might
> help you.  Obviously applications (or in some cases underlying
> libraries, e.g. gtk, qt) would need to be changed.
>
> If you want the ability to run unmodified applications, it might be
> better to use a file system that will save to another location
> automatically, and a single process that monitors that location to tell
> people.

Saving to a temporary file works, as well as the first suggestion done
by Remi. But this is a nightmare in multiuser environments. A second
user uses the original (takes the file before the first user saves),
and saves later, ovrwriting the file saved by the first user.

Locking a file is the most common method, although they are not mandatory.

And about making the fs save the file.
Well that's an idea. But look what happens. The unsaved changes are
kept somewhere by the application, and by writing to another location
automatically, what does that? The whole point is that the app has
unsaved data, which is not on the filesystem. So the filesystem cannot
help you here, that's the whole point. It's the app which should take
action here.

Maybe there is a workaround. I'll look into it. If certain calls are
not supported (like setting a lock) what are apps like swriter do
then? It might be a reasonable choice that swriter automatically
switches to make a copy on a standard place, work on that, and save it
back. When the media is not available anymore, keep it there, and
inform the user. If it's availble just save it, and close th file (yes
all the time it tries to .I'll ask the libreoffice community what they
think of this.

I've tested the behaviour of LibreOffice when working on a document, I
see that the app (swriter) has an fd open on the file.
Now when removing the file self, swriter reports when saving the data
the "file has been changed by others. Overwriting may loose data" or
something like that. This is not the case entirely, I'll report that.

And when removing the directory with the file in it, makes the "Save"
option not available anymore. Neat. So when saving you'll have to
choose the "Save as" option.

I'll look more apps has this behaviour.

Stef


More information about the xdg mailing list