deleting files across file systems

Bug #33212 reported by Jane Silber
Affects Status Importance Assigned to Milestone
Won't Fix
gnome-vfs2 (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

I have my trash on a separate partition from my desktop. If I try to delete a file from the desktop, I get an error message about moving files across file systems (which has some issues, related bug 33210)

I guess that there may be situations when the user should be warned about moving files across file systems (am not sure about that, but am guessing that there must be a reason for the warning/error). But in this case I have explicitly moved my trash to a different file system and don't really want to be stopped or warned about file systems every time I delete something from my desktop. Is it possible to distinguish between the situations that really do merit a warning (whatever they are) and the situation where I clearly do want to move across file systems (in this case by the fact that I moved my trash)?

Changed in nautilus:
assignee: nobody → desktop-bugs
status: Unconfirmed → Confirmed
Changed in gnome-vfs:
status: Unconfirmed → Confirmed
Revision history for this message
beefcurry (jonzwong) wrote :

This is quite strange, I never used to have this problem when deleting files off my NAS in Edgy, however with the recent update to Feisty suddenly I am experiencing the same thing, which means it problely has something to do with device recognition on where the different file system is. I will have to try to see if this also happens on other removable media such as a CF or SD card in FAT/FAT32.

Revision history for this message
Warbo (warbo) wrote :

I get this message when trying to delete things from bound folders in my Home (I keep files in a separate partition, and bind the various folders to the Music, Documents, etc. folders in my home). It forces me to open a terminal just to delete a file (this is using Gutsy, Gnome VFS 1:2.19.91-0ubuntu1, nautilus 1:2.19.91-0ubuntu1)

Revision history for this message
Wilbur Harvey (wilbur-harvey-spirentcom) wrote :

Same problem in Feisty.
In the file manager, go to Edit-->Preferences-->Behaviou and set "Include a Delete command that bypasses Trash"
Then you can, at least, delete the file.
Still broken, but easier to deal with.
In my case, I have a raid, /md0, where directories like /opt, /usr, /var, and /home are bind mounted to /md0/opt etc. This is necessary since the system cannot boot directly off the raid.

Revision history for this message
ne (office-sico) wrote :

Running Feisty:
I have a similar setup as Warbo.
I use different partitions for my data and mount them in some folders in the home directory.

Everything works great for a long time (...since breezy I think) but some days ago I got this error!
But really special is, I get it on only one of my partitions, the other one runs without this problem.
Crazy, isn't it?

But it gets much more wired. Lets call the partition with the error par1 and the other mounted partition par2:
If I try to delete (or send to trash) an image on the broken partition (par1) I get the error: "Not on the same file system"
But if I open the image with gThumb and press the del-key (in gThumb) it is gone.
...but not deleted and not moved to trash, I found the image on the root of par2 (the working partition) after.
I didn' believe and tried it once more: same result.

As in others reports deleting per console (or shift-del) works normal.
Unfortunately this is a production machine, so I cannot do experiments with ..

Revision history for this message
David Tangye (davidtangye) wrote :

I have a similar problem. I always keep all my data on a separate partition, mounted to say /mnt/sdaN. I have a directory there for each user and the user can build whatever subdirectories from there he wants, each with links to his home, eg

ln -s /mnt/sda6/fred/workStuff /home/fred
ln -s /mnt/sda6/fred/playStuff /home/fred
ln -s /mnt/sda6/fred/yetMoreStuff /home/fred, etc

I should be able to use the nautilus Trash facility. I tried creating /mnt/sda6/.Trash-fred but that did not work, and I think it ought to.

Changed in gnome-vfs:
status: Confirmed → Won't Fix
Changed in gnome-vfs:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.