After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 324930 - Nautilus should disallow copying of symlink to FAT drive early
Nautilus should disallow copying of symlink to FAT drive early
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.22.x
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2005-12-24 14:16 UTC by Jonas De Vuyst
Modified: 2018-05-24 10:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Nicer-message-for-EPERM-on-symlink (1.18 KB, patch)
2009-10-25 10:28 UTC, Stéphane Démurget
committed Details | Review

Description Jonas De Vuyst 2005-12-24 14:16:22 UTC
Please describe the problem:
When trying to copy a symlink to a FAT drive one gets a weird error dialog. It
says (I translate):

    Error "Operation not permitted" when copying "$filename".
    Do you want to continue?

    [Cancel] [Retry]

So, first the dialog is phrased oddly. It doesn't explain why the 'operation' is
not permitted, nor what that operation is (a casual user might think 'copying'
is not permitted). Second, there's no use for a retry button.

Thus, a new error dialog should be created.

But possible Nautilus should also never try to copy the symlink in the first
place. Consider the following scenario:

 * You have a file named "A" on a FAT file system (common for thumb drives)
 * You have a symlink "A" on your desktop
 * Drag the symlink to the the FAT file system
 => A dialog pops up "Do you which to replace file A?"
 * You click "overwrite", not realising there's a problem
 => File "A" on the FAT drive is deleted and not replaced by the symlink

This latter part of this bug report is related to bug #64668, but I don't
imagine that bug will ever get fixed.

Note that an alternative solution to this bug could be to copy the target of the
symlink instead of copying the link, whether for all links or only when copying
a link to a different volume (which is already a special case when dragging and
dropping regular files). I think I'd like this behaviour better, but I imagine
this behaviour has been debated and dismissed long ago.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Jonas De Vuyst 2005-12-24 23:10:47 UTC
This just occured to me: Yet another alternative to showing an error dialog, might be to create a .desktop shortcut on file system that do not natively support symlinks.
Comment 2 Stéphane Démurget 2009-10-24 12:59:12 UTC
This bug is rather old (~4y).

Since then the Nautilus UI has been polished a lot and I just tried it displays the following:

  Error while copying "X".
  There was an error copying the file into /media/STOCKAGE-US

  |> Show more details
                                          [Cancel] [Skip]

I think it's less cluttered, and you can notice there is no more Retry button When you click on the expander, you get:

     Error making symbolic link: Operation not permitted

So this is clear the error comes from copying a symlink. Only problem is the technical error reason.

GIO only translates the system translation for the technical error EPERM that roughly translates to "Operation not permitted".

But the manpage of symlink(2) indicates:
"EPERM  The file system containing newpath does not support the creation of symbolic links."

Is it possible for g_local_file_make_symbolic_link to have a special case for EPERM just like the one for EINVAL?

It's up to GIO developers to decide.
This bug should be reassigned to GIO as all the other points have been polished by the years :)
Comment 3 Cosimo Cecchi 2009-10-24 23:36:46 UTC
-> glib/gio

Seems like a sane proposal to me.
Comment 4 Stéphane Démurget 2009-10-25 10:28:49 UTC
Created attachment 146198 [details] [review]
Nicer-message-for-EPERM-on-symlink

Trivial patch, not sure about the wording.
Comment 5 Alexander Larsson 2009-11-05 14:59:19 UTC
Pushed to master
Comment 6 Jonas De Vuyst 2009-11-05 15:29:10 UTC
Hi guys.

I’m afraid I no longer use GNOME so I cannot easily test these patches. Could you tell me what happens when a symlink ‘X’ is copied to ‘/foo/’ when (i) ‘/foo/X’ already exists and (ii) ‘/foo’ doesn’t support symlinks? It used to be the case that in such a situation a dialog would pop up offering to delete ‘/foo/X’ (see also the second part of my original bug report).

Cheers!
Comment 7 Alexander Larsson 2009-11-06 11:15:16 UTC
The patches pushed mainly address (ii) by showing a better error dialog.

I guess we could do better overall by allowing copying the target. I'll reopen this bug to track that.

There is also ongoing work on the conflict dialog so that it shows much more info, which could help make this better.
Comment 8 GNOME Infrastructure Team 2018-05-24 10:38:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/37.