[Geany-devel] Overwriting a link on save as
elextr at xxxxx
Thu Mar 3 00:18:57 UTC 2011
2011/3/3 Enrico Tröger <enrico.troeger at uvena.de>:
> On Wed, 2 Mar 2011 12:50:27 +1100, Lex wrote:
>>> It probably depends on whether we can assume or not that if we
>>> successfully removed the original file we'll be able to create the
>>> new one.
>>> Again, thoughts?
>>g_file_set_contents is documented as behaving the way we want with
>>respect to links so that sounds a good way to go instead of deleting
>>the old file and hoping we can create the new one. Of course on
>>Windows g_file_set_contents has its own set of problems, so
>>technically we should do something else when writing to a windows file
>>(eg via samba) but I don't know how you tell so ignore for now?
> I'm not sure whether this whole problem is a bug or feature :D.
> As Dimitar said, it's rather a feature (or better: just expected
> behaviour), on the other hand, I can imagine that behaviour could be
> quite surprising.
Yep, there are arguments both ways.
As I see it, save means overwrite file named xyz, save as means create
file named xyz replacing it (with a warning) if it already exists
The other behavior is, save means overwrite file named xyz, save as
means create file named xyz,r overwriting it (with a warning) if it
The problem is that when the user doesn't know they are saving to a
link, they destroy a file they didn't mean to!
The situation I am thinking about is the common usage where a generic
link xyz points to specific version xyz.0.1.2, thats fairly common in
I brought up hard links, but on re-thinking that, since hard links are
not links, they are the file by another name, so its not possible to
distinguish, and thankfully multiple hard linking seems to be in
decline since it can't be ported.
So we are only talking about symlinks, which are detectable by glib.
Probably ok to retain the current behavior but we should be user
friendly and provide a warning with ok and continue options if its a
symlink because users don't always remember what is/isn't a link
Windows shortcuts are not links, IIRC if you save to them it replaces
the shortcut not the target so they don't count.
> I tend to fail in guessing most users' preference, so I won't try it
> this time :D.
> Quick weird idea:
> we could add an option in the Save As dialog which is only enabled or
> even shown (though enabling/disabling should be preferred) when a
> target file is selected which is a symlink according to the result of
> g_file_test(filename, G_FILE_TEST_IS_SYMLINK)).
> This option is enabled/disabled according to the currently selected
> file which could be updated by connecting to the "selection-changed"
> signal of the GtkFileChooserDialog.
> Or, less intrusively, when the user chose a filename and finally click
> "OK", we check whether the target file is a symlink and ask the user
> what to do, maybe with a "remember my choice" checkbox.
> As I said, just a quick idea, not sure whether it'd be worth the
> Oh, yeah, as Lex said, we need to think about Windows. Maybe
> G_FILE_TEST_IS_SYMLINK is always false on Windows as there are no real
> symlinks, at least not like on Unix-like systems. I don't know off-hand
> whether GLib considers Windows' shortcuts as symlinks as well. If not,
> it'd be easy. In anyway, this is easy to test on a Windows system.
> Completely no idea about Samba. Maybe G_FILE_TEST_IS_SYMLINK returns
> false in this case as well, always. Need to be tested I guess.
> Just my 2cents.
> Get my GPG key from http://www.uvena.de/pub.asc
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel