Le 03/03/2011 00:08, Enrico Tröger a écrit :
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.
I tend to fail in guessing most users' preference, so I won't try it this time :D.
I personally feel it surprising in the first place, but it's probably because I see the "save as" action as "replace the file" and not as "replace the *content* of the file"... but let's be honest: I personally don't mind and simply felt it more natural. But if there is no clear consensus maybe the better is to decide it's a feature and tell the (few) complaining users.
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.
The main problem (apart the work needed :D) I see is that AFAIK it's not trivial to see whether a file is a hard link in a portable manner. And as Lex pointed out, a hard link has the same issues. And I this maybe a little overkill for such a "small" (and I guess not that common) problem.
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.
The GLib docs says that the IS_SYMLINK test always returns FALSE on Windows, so it'd not be handled... an argument for telling it's a feature, right? ^^
Just my 2cents.
My owns, back. Our counts are clear! :D
Regards, Colomban