GNOME Bugzilla – Bug 314065
"create link" should prompt for a target directory if current directory not writable
Last modified: 2021-06-18 15:28:44 UTC
When right-clicking on a file or folder, "create link" is grayed out if the current directory is not writable by the user. This makes it difficult to create a link to the home directory or to network shares for example. Instead, "create link" could prompt for a target location if the current directory is not writable by the user, without changing the behaviour in the normal case. Thank you Other information:
Thanks for you bug report! I think your proposal is not very useful. Maybe you could describe in detail why you need to place links in directories you don't have write access to.
Ah, now I see what your problem is. Comment 1 wasn't very helpful, sorry. The context-menu feature you use is not meant for creating links in other locations than the target's parent directory. You should middle-click the icon and drop it onto the target directory, selecting "Create link" from the drop context menu.
> You should middle-click the icon and drop it onto the target directory, > selecting "Create link" from the drop context menu. This is terribly non-intuitive. There should an other way to do that in a way non-regular nautilus users (or new nautilus users) will be able to find ... I blocked on this for an hour before deciding to ask a Gnome developer about how to do this. It was a disaster for me, since I was trying to show a friend how gnome is easy to use ...
Usability squad, what do you think?
The first thing I tried was just right-clicking on the Downloads folder in Home, and Create Link. This created a "link to Downloads" in Home - not exactly what I'd expect. It was not capitalized (although that might be an issue with nb-NO, and not other locales?), and I see no use in creating a link in the current directory ... When I want to create a link to a folder (which would be the most common case?), I would most likely want it on my Desktop, in Home, or in the panel. I'd suggest that "Create Link" simply open the standard Save dialog and let you pick a location - but this would not let me link it to the panel, would it ? I noticed with a smile that it's possible to drag a folder to the panel to create a launcher, but it doesn't seem to "preserve" emblems, and since the name of the folder is not included in the panel, you'll have no way of telling several folder launchers from the other (except mousing over them to get the tooltip) if you create many. This is, of course, another bug (although I was unable to find any related bugs in bugzilla - should I report it?). As a sidenote I'd like to mention that whenever I click a link, Nautilus crashes.
> It was not capitalized (although that might be an issue with nb-NO, and not other locales?) Do we want really to capitalize this "link to ..." filename? If yes, it is a bug. "I noticed with a smile that it's possible to drag a folder to the panel to create a launcher, but it doesn't seem to "preserve" emblems, and since the name of the folder is not included in the panel, you'll have no way of telling several folder launchers from the other (except mousing over them to get the tooltip) if you create many. This is, of course, another bug (although I was unable to find any related bugs in bugzilla - should I report it?)." You think that we can fix the issue just by adding emblems? I don't think that many users have a high percentage of their folders stuffed with emblems. > As a sidenote I'd like to mention that whenever I click a link, Nautilus crashes. Eeek! Please read http://live.gnome.org/GettingTraces and file a bug report :).
Reopening since Vidar's proposition sounds like a good idea :-)
:-) Re: comment 6 Filed bug 314175 and bug 314173. And no, I don't think it would be fixed by this, but it might help in some cases. Say distributions create new users with some default directories like "My Documents", "My Downloads", etc, they might also attach some emblems by default. These directories would be some of the best candidates for panel linking, I think. Anyway, should we file a new bug to discuss this, or do you already know if one exists ?
Vidar: I don't think there exists any emblem/panel integration bug report. I just got an idea on the original subject: What if the "linking failed" warning dialog contained an image representing the file we failed to link, allowing you to drag the representation to another arbitrary nautilus window to create a link in it?
Filed bug 314176 about emblem/panel integration. But we're digressing alot here :-) If I think about it in context of my proposal that we use a general Save dialog for it, I think this illustrates an overall problem with the dialog - that you get the impression you are allowed to Save <whatever> in any directory. Trying to save a document in /sbin, for example, just produces an ugly error dialog and throws me back to gedit or whatever, instead of just not showing /sbin in the directory list. I'm guessing this is part of a larger discussion, for example that you might be allowed to save to a subdirectory? Of course fixing this in a sensible way with the general Save dialog wouldn't solve the problem if a user middle-clicks and DnD's it to a directory where he's not allowed to write ... Say I access my NTFS (where I do not have write access) disk in Nautilus and right-click a folder; the "Cut", "Paste", "Create Link", "Rename", etc, actions are greyed out. But, if I middle-click, drag, and release the same folder, the "Move here", "Copy here" and "Create Link here" actions are not greyed out. Why not?
> if I middle-click, drag, and release the same folder, the "Move here", "Copy here" and "Create Link here" actions are not greyed out. Why not? This is a totally different issue, although you are right. It won't even be very hard to fix. I just fear users will not grasp why we display a popup which just contains disabled icons. Maybe we should just not drag highlight on a read-only folder. On the other hand, on our way to 2.14 we might add authentication/sudo caps to the dialog complaining that the user doesn't have enough permissions. Therefore, comment 10 and comment 11 don't help a lot on this particular issue.
Agreed, different issue, filed bug 314200. My proposal is * When you click "Create Link" it opens the standard Save dialog with Name preset to "Link to ..." and Folder set to "Desktop". * When you "middle-drag" an entity and choose "Create link here" it opens the standard Save dialog with the Name preset to "Link to ..." and Folder set to the target of the DnD. Now maybe someone from the Usability SWAT team could comment on this proposal :-)
Today, I found this "bug" when I was trying to create a shortcut in my desktop to a document in /usr/shr/doc. If I can do a "copy" operation of de document, why can I do a "make link" operation instead of a paste? What I mean, wouldn't it be possible to add a "paste link" to the already existing option "paste"?
I'm not sure if this was mentioned yet or not here. My two cents: 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.
*** Bug 358205 has been marked as a duplicate of this bug. ***
*** Bug 704656 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.