GNOME Bugzilla – Bug 534432
Nautilus always uses "Link to ..." as symlink filenames
Last modified: 2009-03-07 14:20:01 UTC
First filed here: https://bugzilla.redhat.com/show_bug.cgi?id=447624 Description of problem: When making symbolic links to files, Nautilus prepends "Link to" to the name of the original file. The original filenames are good as they are and I can recognize symbolic links by their arrow corner symbol. Version-Release number of selected component (if applicable): nautilus-2.22.2-7.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Make a symbolic link from one file in another folder. Actual results: Name of the symbolic link is "Link to <original file name>" Expected results: I'd like to switch back to the old behaviour, where the symlink filename was the same as the original file (if no other file of that name existed). Patch provided by Nils Philippsen <nphilipp@redhat.com> diff -up nautilus-2.22.2/libnautilus-private/nautilus-file-operations.c.no_link_to nautilus-2.22.2/libnautilus-private/nautilus-file-operations.c --- nautilus-2.22.2/libnautilus-private/nautilus-file-operations.c.no_link_to 2008-05-20 22:29:14.000000000 +0200 +++ nautilus-2.22.2/libnautilus-private/nautilus-file-operations.c 2008-05-20 22:51:12.000000000 +0200 @@ -240,9 +240,9 @@ get_link_name (const char *name, int cou g_assert (name != NULL); - if (count < 1) { + if (count < 0) { g_warning ("bad count in get_link_name"); - count = 1; + count = 0; } if (count <= 2) { @@ -253,6 +253,10 @@ get_link_name (const char *name, int cou default: g_assert_not_reached (); /* fall through */ + case 0: + /* leave it as it is */ + format = ("%s"); + break; case 1: /* appended to new link file */ format = _("Link to %s"); @@ -4290,7 +4294,7 @@ link_file (CopyMoveJob *job, common = (CommonJob *)job; - count = 1; + count = 0; dest = get_target_file_for_link (src, dest_dir, count);
I had a suggestion for the same in bug 538249 PASTE AS LINK: The most common use of creating a link in Linux is to access a file or script using the SAME NAME. It's very annoying that you have to move the file and then rename the it after the file browser puts a "Link to" at the beginning. That functionality is fine if you provide a "Paste as Link" context menu item. Also provide a hot key such as Ctrl+Shift+V.
Just wanted to say that I agree. This behaviour is very annoying and gives me a lot of extra work. For now I have installed a few other file managers, which I don't really like, but at least they don't mess with my link names. I would like this to be selectable by the user, something like this: ☒ Apply text to link names: [<A field here for text to apply>] ☉ Apply text before file name ⃝ Apply text after the file name (before the suffix) This would probably fit into most user's taste. Now, a link to ”My File.txt” could be named ”My File.txt”, ”Link to My File.txt”, ”My File – link.txt”, ”My File (Link).txt” and so on, depending on what the user wants. Everybody's happy, right? ☺
*** Bug 541114 has been marked as a duplicate of this bug. ***
The most amazing thing is that older versions of Gnome did this right. http://ubuntuforums.org/showthread.php?p=5544079#post5544079 Can we expect the next Gnome version to be right again?
Absolutely true. Imagine the following situation: I want to compile a latex file and I want to link a bunch of heavy .eps figures in the directory where the file resides so they may be found by latex. With the new behavior I get a bunch of "Link to...", completely unuseful, then I have to change all the names by hand! So I go back to using a terminal. But this is not how it's supposed to work. If someone loves this "Link to...", then put it into a configuration variable so that it can be changed. And leave it without the "Link to..." as default. The creaction of links was perfect in the previous version of Nautilus, it was a bad idea to change it.
It would be nice if some developer could explain what's the rationale behind the new behaviour. Maybe we're missing something?
"I am not a developer", but since that is a clone of the Windows shell behavior, I would guess that the idea is to ease migration of Windows users to the Gnome desktop. However not everything the Windows guys are doing is the right thing. As the people above said, that new behavior is irritating. The same problems are troubling me (having to use the shell to create links or rename links created with Nautilus etc). This is simply not the way things work in Linux. I reckon that the loss is greater than the gain. It's OK to do things a bit different if the way we do it makes more sense.
(In reply to comment #7) > "I am not a developer", but since that is a clone of the Windows shell > behavior, I would guess that the idea is to ease migration of Windows users to > the Gnome desktop. Great. What's the next step? Drive letters? While waiting for a fix of this bug (yes, to me it is a bug) I use an alias to automatically remove every "Link to " from every file name in the current folder and all its sub folders: alias rmlt='find . -type l -exec rename -v "s/Link to //" {} +' I added the line above to a file containing other aliases, and the file is loaded at login. Unfortunately, when there are two links in the same folder that point to the same file, one of them is called "Another link to..." (or something like that; I have the Swedish version installed). If this is the case, I guess more aliases could be created: alias rmlt1='find . -type l -exec rename -v "s/Yet another link to //" {} +' alias rmlt2='find . -type l -exec rename -v "s/Another link to //" {} +' alias rmlt3='find . -type l -exec rename -v "s/Link to //" {} +' Then run them one by one, rmlt1 first and so on. Or make a script that does the same thing: #!/bin/sh find . -type l -exec rename -v "s/Yet another link to //" {} + find . -type l -exec rename -v "s/Another link to //" {} + find . -type l -exec rename -v "s/Link to //" {} + I've only tested the first alias, so I am not sure wether the other suggestions work or not. Use them at your own risc. Oh, and "rename" is the Pearl based rename by Larry Wall. It's obviously only available in Debian based distros. Here are instructions how to add it to other distros: http://tips.webdesign10.com/how-to-bulk-rename-files-in-linux-in-the-terminal Scroll down to about 60% or so.
(In reply to comment #7) > "I am not a developer", but since that is a clone of the Windows shell > behavior, I would guess that the idea is to ease migration of Windows users to > the Gnome desktop. If that's the case, they should provide a tweak in Gconf. (It's been there for ages in the Windows registry and it's one of the first things I used to do when setting up Windows machines.) Failing to do so set's us back to the irrational situation we're facing.
I just discussed the issue with Alexander on IRC, and it turns out that it is an accidental regression from GIO migration. Sorry that it took us nine months to fix it: 2009-02-20 Christian Neumair <cneumair {at} gnome.org> * libnautilus-private/nautilus-file-operations.c (get_link_name), (link_file): Do not put "Link to ..." in front of symbolic links that are created in another directory via DND. Fixes #534432. http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14982 http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14983 Closing.
Sorry to reopen, but in rev 14983, you introduced this string for translation: format = _("%s") I don't understand why you'd want to pass a single format string to gettext. This has no sens in a translator point of view.
That was likely a typo, as we were marking for translation a file name... This is fixed in trunk now. 2009-03-07 Cosimo Cecchi <cosimoc@gnome.org> * libnautilus-private/nautilus-file-operations.c (get_link_name): don't mark for translation a file name, as it's pointless (#534432).