gvfs-trash fails on file in a symbolic linked folder in a different file system

Bug #1512521 reported by Bruno Marinho
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gvfs (Ubuntu)
Confirmed
High
Unassigned

Bug Description

I have Documents in a LUKS container mounted and symlinked on my home folder.
  |-- Documents -> secure/documents
Have other folders like Desktop in a ecryptfs folder mounted and symlinked on my home folder.
  |-- Desktop -> Private/Desktop
So when I delete a file on Desktop or Documents it fails. It seems like it's saving the file in .local/share/trash instead of inside the containers. I was using fedora 22 and it was working fine. Now moved to ubuntu 15.10 and doesn't seem to work.
strace of trying to delete the file:

openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
lstat("/home/zed/Documents/secure-trash.txt", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
stat("/home/zed", {st_mode=S_IFDIR|0700, st_size=894, ...}) = 0
lstat("/home/zed/Documents", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0
access("/home", F_OK) = 0
stat("/home", {st_mode=S_IFDIR|0755, st_size=50, ...}) = 0
access("/home/zed", F_OK) = 0
stat("/home/zed", {st_mode=S_IFDIR|0700, st_size=894, ...}) = 0
access("/home/zed/.local", F_OK) = 0
stat("/home/zed/.local", {st_mode=S_IFDIR|0700, st_size=10, ...}) = 0
access("/home/zed/.local/share", F_OK) = 0
stat("/home/zed/.local/share", {st_mode=S_IFDIR|0700, st_size=224, ...}) = 0
access("/home/zed/.local/share/Trash", F_OK) = 0
stat("/home/zed/.local/share/Trash", {st_mode=S_IFDIR|0700, st_size=34, ...}) = 0
mkdir("/home/zed/.local/share/Trash/info", 0700) = -1 EEXIST (File exists)
mkdir("/home/zed/.local/share/Trash/files", 0700) = -1 EEXIST (File exists)
open("/home/zed/.local/share/Trash/info/secure-trash.txt.trashinfo", O_RDONLY|O_CREAT|O_EXCL, 0666) = 3
close(3) = 0
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3687, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=3687, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb9f31b000
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 3687
lseek(3, -2347, SEEK_CUR) = 1340
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 2347
close(3) = 0
munmap(0x7feb9f31b000, 4096) = 0
open("/home/zed/.local/share/Trash/info/secure-trash.txt.trashinfo.DITD7X", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
fallocate(3, 0, 0, 94) = 0
write(3, "[Trash Info]\nPath=/home/bpmarinh"..., 94) = 94
fstatfs(3, {f_type=0x9123683e, f_bsize=4096, f_blocks=119953152, f_bfree=76651779, f_bavail=76103891, f_files=0, f_ffree=0, f_fsid={-810601384, -1547478495}, f_namelen=255, f_frsize=4096}) = 0
close(3) = 0
rename("/home/zed/.local/share/Trash/info/secure-trash.txt.trashinfo.DITD7X", "/home/zed/.local/share/Trash/info/secure-trash.txt.trashinfo") = 0
rename("/home/zed/Documents/secure-trash.txt", "/home/zed/.local/share/Trash/files/secure-trash.txt") = -1 EXDEV (Invalid cross-device link)
unlink("/home/zed/.local/share/Trash/info/secure-trash.txt.trashinfo") = 0
open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
writev(3, [{"*** Error in `", 14}, {"gvfs-trash", 10}, {"': ", 3}, {"double free or corruption (fastt"..., 35}, {": 0x", 4}, {"0000000001222aa0", 16}, {" ***\n", 5}], 7*** Error in `gvfs-trash': double free or corruption (fasttop): 0x0000000001222aa0 ***
) = 87
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb9f31b000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(5432, 5432, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=5432, si_uid=1000} ---
+++ killed by SIGABRT (core dumped) +++
Aborted (core dumped)

Found this one but doesn't seem like it's fixed on 15.10:

https://bugzilla.gnome.org/show_bug.cgi?id=748248
https://bugzilla.gnome.org/show_bug.cgi?id=748629

Revision history for this message
Bruno Marinho (bruno-pmarinho) wrote :

I actually noticed this on thunar but I drilled it down to gvfs-trash.

affects: gnome-vfs (Ubuntu) → gvfs (Ubuntu)
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

Changed in gvfs (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Bruno Marinho (bruno-pmarinho) wrote :

As requested, attached a proper strace generated per documentation supplied.

The situation is simple to reproduce: create a container, create a link, add a file and trash the file from the link instead of the real path.

Revision history for this message
Bruno Marinho (bruno-pmarinho) wrote :

After adding the request information what is the status? "New" or "In progress"?

Changed in gvfs (Ubuntu):
status: Incomplete → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed
Revision history for this message
Sergey (sergey162008) wrote :

I have the same bug in Ubuntu 16.04.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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