cannot delete files off of an Fuse mounted NTFS partition in nautilus

Bug #186569 reported by Matthew McGowan on 2008-01-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
glib2.0 (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gvfs

Using the new gvfs nautilus in Hardy I cannot delete files from a Fuse-mounted NTFS partition.

The error i recieve is the following:
Error removing file: File exists

I can however cut and paste the files to my home directory, and then delete them.

Related branches

Kow (kow) wrote :

I am guessing we have the same issue but just to clarify... The problem I have only involves deleting a folder with sub-folders or files. I can delete a file or an empty directory just fine but not otherwise. I should also say this only happens with the permanent Delete command (must be turned on in the Nautilus settings to see the option in right click dropdown menu) but NOT with "Move to Trash". I think that works fine as there are no errors and they disappear from the file viewer but since its NTFS I'm not sure how trash works if at all different.My thoughts are that GVFS is passing the command "upstream" to delete the folder, and then the file. Somehow the files need to be deleted first. Perhaps getting upstream to fix this would be the better solution however I'm not quite sure how far to go... glib calls on posix for file/folder operations. rm -R works fine.


1. Using nautilus make a temp folder on a NTFS mountpoint/partition and create an empty file and name it test (the folder and file can be named arbitrarily.)

  a. Make sure delete command is enabled in Nautilus Preferences -> Behavior.

2. Right Click on the temp folder and "Delete"

3. Under "Show more details" of the error window "Error removing file: File Exists". Alright I tried Skip, Skip All, and Cancel and no difference - test folder and subfile still exist.

4. I can remove the file first and then the folder just fine from Nautilus.

5. "rm -R test" works just fine.

Matthew McGowan (mmcg069) wrote :

Yes you are correct. We have the same issue.

So to clarify. Single files _can_ be deleted but you cannot Move to Trash. You get an error:

Cannot move file to trash, do you want to delete immediately?
  The file "xyz" cannot be moved to the trash.

Similarly, empty folders can be deleted, but cannot be moved to the trash folder.

Any folder that contains sub-dirs or files cannot be deleted or moved to the trash folder.

SK (stephantom) wrote :

See also this ( post for more information on this report.

Kow (kow) wrote :

I have no troubles using the trash, the said problems are with the Delete command only.

Kow (kow) wrote :

Nautilus handles trash itself I think. If its the delete command it almost instantly gets passed along to gvfs.

Homersp (maa-tillman) wrote :

I have the same problem on Ubuntu 8.04 (alpha).
Single files work fine to delete, but not directories that are not empty.
I don't think I've seen this problem in earlier versions of Ubuntu (7.10 for example), but I could be wrong.

SK (stephantom) on 2008-02-13
Changed in gvfs:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Could somebody describe easy steps to trigger the issue?

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Confirmed → Incomplete
Matthew McGowan (mmcg069) wrote :

Try and delete a folder with a file in it, off of a fuse mounted ntfs partition/drive.

Sebastien Bacher (seb128) wrote :

how do you fuse mount a ntfs partition?

Matthew McGowan (mmcg069) wrote :

My apologies, i was being overly specific. As long as you have an NTFS partition, ubuntu mounts it with fuse by default, so dont worry about that bit.

If you do have a NTFS partition, try and delete a folder with a file in it, off of a the mounted ntfs partition/drive.

Sebastien Bacher (seb128) wrote :

That's a ntfs-3g issue, rmdir on an existant directory returns EEXIST and not ENOTEMPTY as it should

Changed in gvfs:
assignee: desktop-bugs → nobody
importance: Low → High
status: Incomplete → Confirmed
Martin Pitt (pitti) on 2008-02-21
Changed in ntfs-3g:
assignee: nobody → pitti
status: Confirmed → In Progress
Szabolcs Szakacsits (szaka) wrote :

Sebastien Bacher wrote:
"That's a ntfs-3g issue, rmdir on an existant directory returns EEXIST and not ENOTEMPTY as it should"

You're quite mistaken. Both are correct and file systems use both values:

NTFS-3G uses EEXIST because more software handle the relevant error scenario better that way. Seemingly that doesn't include Nautilus.


NTFS-3G Lead Developer:

Sebastien Bacher (seb128) wrote :

the ubuntu disagrees and doesn't list EEXIST there

Matti Lindell (mlind) wrote :

Here's a test case from one of the duplicates:

1. create a ntfs loopback file and mount it
$ sudo aptitude install ntfsprogs
$ dd if=/dev/zero of=/tmp/blah bs=1M count=2
$ sudo losetup /dev/loop0 /tmp/blah
$ sudo mkfs.ntfs /dev/loop0
$ sudo losetup -d /dev/loop0
$ mkdir /tmp/foo
$ sudo mount -t ntfs-3g /tmp/blah /tmp/foo

2. create a directory structure
$ mkdir -p /tmp/foo/bar/baz

3. try to remove /tmp/foo/bar using nautilus. A "Error while deleting." message should appear.

Christophe Olinger (olingerc) wrote :

Ubuntu Hardy alpha 5 here. Problem persists.

warmrobot (imfrolov) wrote :

Confirm this bug on alpha 5

Alperen Yusuf Aybar (alperen) wrote :

I can confirm this annoying bug on Hardy Alpha 5

Martin Pitt (pitti) wrote :

I filed a bug in Debian about the manpage problem:

Changed in ntfs-3g:
assignee: pitti → desktop-bugs
milestone: none → ubuntu-8.04
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glib2.0 - 2.15.6-0ubuntu2

glib2.0 (2.15.6-0ubuntu2) hardy; urgency=low

  * debian/patches/80_from_bugzilla_rmdir_can_return_eexist.patch:
    - change from bugzilla, fix some issues with ntfs3g (lp: #186569)

 -- Sebastien Bacher <email address hidden> Tue, 26 Feb 2008 12:37:26 +0100

Changed in glib2.0:
status: In Progress → Fix Released
Matthew McGowan (mmcg069) wrote :

Yep seems fine for me.

Changed in gvfs:
status: Unknown → Fix Released
John M (jwmwalrus) wrote :

I just installed the beta, and I'm having the same problem. In Gutsy, when I tried to delete a file in a ntfs-3g partition, it used to be moved to the .Trash-${USERNAME} folder, but now I always get the message "Cannot move file to trash, do you want to delete immediately? The file "new file" cannot be moved to the trash.".


...:~$ lsb_release -rd
Description: Ubuntu hardy (development branch)
Release: 8.04

...:~$ apt-cache policy libglib2.0-0
  Installed: 2.16.1-1ubuntu3
  Candidate: 2.16.1-1ubuntu3
  Version table:
 *** 2.16.1-1ubuntu3 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

...:~$ apt-cache policy nautilus
  Installed: 1:2.22.0-0ubuntu3
  Candidate: 1:2.22.0-0ubuntu3
  Version table:
 *** 1:2.22.0-0ubuntu3 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

...:~$ apt-cache policy gvfs
  Version table:
 *** 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

Sebastian Meyer (wastl) wrote :

I can confirm this bug. In Nautilus, any files/directories on my ntfs-3g partition can be deleted, but they can not be moved into the trash folder. I get the same message as John: "Cannot move file to trash, do you want to delete immediately? The file [...] cannot be moved to the trash."
I am using ubuntu hardy final release 8.04 on amd64 with

...:~$ apt-cache policy libglib2.0-0
  Installed: 2.16.3-1
  Candidate: 2.16.3-1
  Version table:
 *** 2.16.3-1 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

...:~$ apt-cache policy nautilus
  Installed: 1:2.22.0-0ubuntu4
  Candidate: 1:2.22.0-0ubuntu4
  Version table:
 *** 1:2.22.0-0ubuntu4 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

...:~$ apt-cache policy gvfs
  Installed: 0.2.3-0ubuntu4
  Candidate: 0.2.3-0ubuntu4
  Version table:
 *** 0.2.3-0ubuntu4 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

Could this problem also be related to mount options?

Thanks in advance,

Sebastien Bacher (seb128) wrote :

don't comment on closed bugs, the trash issue is bug #192629 and a different issue

Changed in gvfs:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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