nautilus tries to move when dragging and dropping from read-only folders, instead of copying

[Matthew East]

1. Open nautilus
2. Go to a directory where the user only has read access, not write access (e.g. /usr/share/example-content)
3. Try and drag and drop a file onto the desktop

Expected Result: Nautilus copies the file only the desktop
Actual Result: Nautilus tries to move the file, and returns an error about permissions

Matt

[Sebastien Bacher (seb128)]

Thanks for your bug. What version of Ubuntu do you use? What mouse button do you use? Do you press any modifier on the keyboard while doing that? What error do you get? Could you copy the exact message? Are those on different partitions or not? That works fine for me on my dapper installation

[Matthew East (mdke)]

On Fri, 2006-04-14 at 12:11 +0000, Sebastien Bacher wrote:
> What version of Ubuntu do you use?

Dapper, fully updated.

> What mouse button do you use?

Left.

> Do you press any modifier on the keyboard while doing that?

No

> What error do you get? Could you copy the exact message?

Error while moving.
"/home/matt...splash.xcf" cannot be moved because you do not have
permissions to change it or its parent folder.

> Are those on different partitions or not?

Same partition (/usr/share/example-content)

 status unconfirmed

HTH, Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

[Sebastien Bacher (seb128)]

is that specific to that directory? Does anybody else get that issue?

[Matthew East (mdke)]

On Wed, 2006-04-26 at 19:56 +0000, Sebastien Bacher wrote:
> is that specific to that directory?

No, happens with any folder where my user doesn't have write access.

> Does anybody else get that issue?

I'll try it on a fresh user and report back.

Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

[Simon Law (sfllaw)]

Reproduction steps:

1. cd ~
2. mkdir readonly
3. touch readonly/sfllaw
4. chmod 0500 readonly
5. Open Places > Home Folder
6. Find readonly, which should have a locked tag on it.
7. Double-click readonly.
8. Left-drag sfllaw to your Home Folder.

Expected result:
1. Dragging produces a copy mouse cursor.
2. Letting go causes a copy of sfllaw to be created in Home
Folder.

Actual result:
1. Dragging produces a move mouse cursor.
2. An error dialog pops up saying:

Error while moving.
"/home/sflla...only/sfllaw" cannot be moved because you
do not have permissions to change it or its parent folder.
                                           Cancel Retry

[Sebastien Bacher (seb128)]

That testcase is buggy on my installation too but I'm not sure that's the same issue than the bug described first since it works fine for some /usr directory

[Matthew East (mdke)]

just to confirm/clarify: this happens to me on a fresh user account too. The problem happens when I try and drag any file I don't have write permissions on, to a place which I do have them (i.e. /etc/ or /usr/ to ~/Desktop)

Matt

[Matt Zimmerman (mdz)]

I can confirm this both on current Dapper daily live CDs, and on fresh, erase-disk installs from them. No weird partitioning or suchlike at all.

What can I do to debug this?

[Sebastien Bacher (seb128)]

The bug happens only when the source and directory are on the same partition, that's why it didn't happen on my Desktop. Matt, do you think that's something which should be fixed for dapper?

I worked on it yesterday, I think that would require some change to libnautilus-private/nautilus-dnd.c nautilus_drag_default_drop_action_for_icons() probably but I'm not that comfortable do that changes to that code just before dapper, maybe something for dapper-updates? The bug happens on FC5 too according to vuntz who tried, so it's not due to a distro patch or a recent upstream change

[Matt Zimmerman (mdz)]

Is it a regression from Breezy?

[Matt Zimmerman (mdz)]

OK, I checked Breezy, and it doesn't have this bug (though it has the bug where the file is set read-only)

[Sivan Greenberg (sivan)]

in 93_upstream_nautilus-dnd-user-owned.patch inside the source package, there is already a patch that modified the behavior of nautilus_drag_default_drop_action_for_icons(..

I am thinking along the lines of something similar to that patch, to change the default behavior from move to copy when the source is readonly as in this bug's test case.

that would involve:
1) Creating a function using gnomevfs that checks if the source is readonly
2) add modifer to the " if (same_fs || target_is_source_parent)...." condition, as 93_upstream_nautilus-dnd-user-owned.patch already does.

[Sivan Greenberg (sivan)]

fix for this bug

[Sivan Greenberg (sivan)]

debdiff to fix this bug without the embarrasing left over g_warnings

[Sivan Greenberg (sivan)]

attached a modified patch that does not include the left over g_warning. Now only needs a sponsered upload, and I would love to see it fixed for the release :-)

[Sebastien Bacher (seb128)]

Thank you for the work on that. That sort of code change will not be used now for dapper but we will fix it with dapper-updates, I'll comment on the patch later

[Sivan Greenberg (sivan)]

k, thanks Seb , let me know if you want anything changed on the patch after you test it.

[Sivan Greenberg (sivan)]

I've started a discussion about the right way to solve this with Alex Larsson , the upstream maintainer. He has provided me some guidance and his design of the issue. I will work on a patch upstream soon.

[Sivan Greenberg (sivan)]

I'm currently lacking time to come up with a patch as Alex wants it, unassigning - anybody is encouraged to read the backlog, as well as the discussion on nautilus development mailin glist and finish this fix.

[Matthew East (mdke)]

I still see this bug in Feisty.

It's insane that I can drag a read-only file into my remote-server mounted on the desktop, but when I try to do it to the desktop, it fails.

[DavidL (dlandis)]

I also experience this identical behavior on Edgy. I am a new user and actually quite surprised drag-and-drop files has such poor support on an OS everyone says is "ready for the desktop".

And the urgency is marked as low! It is the most basic function of a file manager. I'm sorry but this is totally pathetic.

[Matthew East (mdke)]

No change in gutsy. Gutsy can do so many clever things, but not this basic one.

[Sebastien Bacher (seb128)]

could you try if that's still an issue on hardy? it should be fixed using the new gio version

[Sebastien Bacher (seb128)]

hum, no, that's still an issue

[Sebastien Bacher (seb128)]

the bug has been fixed upstream now

[Sebastien Bacher (seb128)]

the issue is fixed in jaunty now