2011/3/3 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 2 Mar 2011 12:50:27 +1100, Lex wrote:
Hey,
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 already exists.
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 some places.
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.
Cheers Lex
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 efforts.
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.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel