"Save" of existing file in a mountpoint of archivemount is lost, "Save As" works for new files only.

[db-inf]

I use archivemount ( FUSE Filesystem in Userspace) to mount an archive, with an empty directory as mountpoint. Writing to that mountpoint is handled transparently by archivemount: changes in the filesystem are visible immediately, but only written back to the archive on unmount.

Geany can open both files that pre-existed in the mounted archive, and files that are changed or newly created after mounting the archive to the mountpoint.

But Geany's 'File/Save' operations are lost. You get the message "11:35:28: File ... saved.", without any error message, but the change is lost, the file is not changed, not even it's timestamp.

When you save an existing file with 'File/Save as' to it's existing name, the change is lost as with 'File/Save'.

'File/Save as' to a new filename works without problems: the new file is created, and it's contents saved.

I tried several other programs (command line, Libreoffice Writer, mousepad) with and during the same mount, and they have no problem saving existing nor new files. I suppose it is a Geany problem.

[elextr]

Have a look at https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving and try varying the file saving settings.

[db-inf]

My preferences were the default, 'use_gio_unsafe_file_saving'. I tryed the others, and can conclude:

• 'use_gio_unsafe_file_saving' checked, with 'use_atomic_file_saving' unchecked, does not save to an existing file, but does save to a new file
• 'use_atomic_file_saving' checked, with 'use_gio_unsafe_file_saving' unchecked, does not save to an existing file, but does save to a new file
• with both the above options unchecked, geany itself does save to both existing and new files

This is strange behaviour, because according to the link All you never wanted to know about file saving 'use_atomic_file_saving' always writes to a temporary new file first, and then renames that to the name of the existing file. So at least the temporary file should be available after fail, but it is not.

[db-inf]

I found more about this. The temporary file written with the methods 'use_atomic_file_saving' and 'use_gio_unsafe_file_saving' is named like this : /tmp/archivemount_.goutputstream-0HQLEZ_EWe3lj and it stops there.

When I do a move on the command line mv /tmp/archivemount_.goutputstream-0HQLEZ_EWe3lj /mnt/existingfile.txt it is renamed to something like /tmp/archivemount_existingfile.txt_L801KG and the changed content is accessible from the mountpoint.

When it is written with the method programmed in geany itself, it is immediataly named like this: /tmp/archivemount_existingfile.txt_SFb30S and the changed content is immediately accessible from the mountpoint, without needing my intervention to move explicitely

Of course the /tmp/archivemount_.goutputstream-... gives me no indication of what name it should be, if there are many of these files, and the command-line move procedure is therefor not practical.

[elextr]

It appears that the rename()system call does not actually work correctly on archivemount filesystems but must tell Glib that it does or there would be an error message. (Note the command line mv program will fall back to doing a copy not a rename, so it will still work without rename()).

[db-inf]

A further test shows that with gio_unsafe_save_backup ON in addition to gio_unsafe_file_saving, saving on an archivemounted file system does work. With this flag on, the on-disk copy of the file-to-be-saved is moved out of the way by renaming it with a '~' appended to it's name first. Surprisingly enough modifiying and saving the file again, it's backup copy is replaced correctly as well, with the previous modified file version. So the backup file is first removed, then the original file is renamed, and then the changed file is renamed from it's temporary name to it's original name.

Of course you get backup files with a '~' appended to their name all over the place.

[elextr]

GIO does some strange things, you need to strace the operations being done, but I suspect the backup is a copy and the original file is made by overwriting the original. I don't remember exactly what conditions made it do that instead of rename and new file and rename.

[Edit: I think it was to do with protections, and ownerships and other metadata]