Hi all,
A user (yecril71pl) on #geany reported that saving as a file with the name of a symbolic link correctly ask for replacing but will try to modify the file at the location pointed by the link rather than replacing the link by a new file. This is IMHO at least not expected, and may be problematic if e.g. the target of that link isn't writable, since the write will fail (if using unsafe file saving).
I then suggest to delete the file on "save as" if we see it's a symbolic link, so we will create a fresh new file with the proper name.
I attach a patch for this, but I'm not sure it's really the right way/place to do this.
Any thoughts?
Kind regards, Colomban
On 2 March 2011 10:57, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi all,
A user (yecril71pl) on #geany reported that saving as a file with the name of a symbolic link correctly ask for replacing but will try to modify the file at the location pointed by the link rather than replacing the link by a new file. This is IMHO at least not expected, and may be problematic if e.g. the target of that link isn't writable, since the write will fail (if using unsafe file saving).
Hi Colomban,
It does the same with hard linked files, ie it modifies the file rather than replacing it, and so changes the file for all the links, again probably not what was expected. So I think "save as" should always delete the file (if it exists) before saving, not just on symlink.
Cheers Lex
I then suggest to delete the file on "save as" if we see it's a symbolic link, so we will create a fresh new file with the proper name.
I attach a patch for this, but I'm not sure it's really the right way/place to do this.
Any thoughts?
Kind regards, Colomban
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 02/03/2011 01:59, Lex Trotman a écrit :
On 2 March 2011 10:57, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi all,
A user (yecril71pl) on #geany reported that saving as a file with the name of a symbolic link correctly ask for replacing but will try to modify the file at the location pointed by the link rather than replacing the link by a new file. This is IMHO at least not expected, and may be problematic if e.g. the target of that link isn't writable, since the write will fail (if using unsafe file saving).
Hi Colomban,
It does the same with hard linked files, ie it modifies the file rather than replacing it, and so changes the file for all the links, again probably not what was expected. So I think "save as" should always delete the file (if it exists) before saving, not just on symlink.
Right, good point. However removing the file have drawbacks, such as we might not be able to create it back if e.g. we don't have write permissions on the parent directory but only on that particular file -- though, AFAIK you can't remove a file in a directory you can't write to, so it isn't a problem.
OTOH maybe it's anyway not a real problem to lose the file upon wired failure when use_safe_file_saving is false?
Maybe the best fix would be to use g_file_set_contents() (aka safe file saving currently) when saving as? So we don't lose the original if we haven't the new one... but we then assume that safe file saving is implemented as temp file writing and rename. 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?
Regards, Colomban
On 2 March 2011 12:26, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 02/03/2011 01:59, Lex Trotman a écrit :
On 2 March 2011 10:57, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi all,
A user (yecril71pl) on #geany reported that saving as a file with the name of a symbolic link correctly ask for replacing but will try to modify the file at the location pointed by the link rather than replacing the link by a new file. This is IMHO at least not expected, and may be problematic if e.g. the target of that link isn't writable, since the write will fail (if using unsafe file saving).
Hi Colomban,
It does the same with hard linked files, ie it modifies the file rather than replacing it, and so changes the file for all the links, again probably not what was expected. So I think "save as" should always delete the file (if it exists) before saving, not just on symlink.
Right, good point. However removing the file have drawbacks, such as we might not be able to create it back if e.g. we don't have write permissions on the parent directory but only on that particular file -- though, AFAIK you can't remove a file in a directory you can't write to, so it isn't a problem.
OTOH maybe it's anyway not a real problem to lose the file upon wired failure when use_safe_file_saving is false?
Its ALWAYS a problem to lose a file you don't expect to.
Maybe the best fix would be to use g_file_set_contents() (aka safe file saving currently) when saving as? So we don't lose the original if we haven't the new one...
Good idea.
but we then assume that safe file saving is
implemented as temp file writing and rename.
Well its documented as doing that, so we are not depending on an undocumented implementation feature.
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?
Cheers Lex
Regards, Colomban
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.
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
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
On Thu, 03 Mar 2011 00:56:14 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
First of all, congratulations!
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.
Every *nix regular file/directory name is a hardlink; there is no "primary file name" and "additional links". Normally one would check the number of links with stat(2).
However, one hardlink is no different from another; they are all THE file to be saved. So why would anyone expect a new file to be created when saving to the actual file?.. I side with Lex here: if there's something to be done, it should be for the symlinks only.
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
Am 02.03.2011 00:57, schrieb Colomban Wendling:
This is IMHO at least not expected, and may be problematic if e.g. the target of that link isn't writable, since the write will fail (if using unsafe file saving).
Am I the only one who does expect this?
If I use symbolic links I want to have second name for a file, so if I call the second name I really mean the original one. Otherwise I'd just copy the file.
Best regards.
Am 02.03.2011 11:06, schrieb Thomas Martitz:
Am I the only one who does expect this?
If I use symbolic links I want to have second name for a file, so if I call the second name I really mean the original one. Otherwise I'd just copy the file.
Reading it a second time I see it's about "Save as...", so a different case. You guys are right then. Sorry for the noise.
Best regards.
On Wed, 02 Mar 2011 00:57:01 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
A user (yecril71pl) on #geany reported that saving as a file with the name of a symbolic link correctly ask for replacing but will try to modify the file at the location pointed by the link rather than replacing the link by a new file. This is IMHO at least not expected,
Why should it be unexpected?..
$ echo boza1 > boza1 $ ln -s boza1 boza2 $ echo boza2 > boza2 $ cat boza1 boza2
and may be problematic if e.g. the target of that link isn't writable, since the write will fail (if using unsafe file saving).
chmod -w boza1 Geany File -> Save as -> boza2
"Error opening file '/home/build/boza2': Permission denied The file on disk may now be truncated!"
I then suggest to delete the file on "save as" if we see it's a symbolic link, so we will create a fresh new file with the proper name.
Any thoughts?
Just what's the purpose of a link, be it soft or hard, if it does not behave as a link?.. There is no such category as "link on read, but non-link on write". If somebody wants to unlink a file, (s)he can do that with any shell or file manager.
I tried ne, mousepad and scite, and none of them removes symlinks on Save As. It may be different for gedit, of course.