Nautilus crashes when delete a file in a folder which is a symbolic link to another filesystem

[Rodrigo Renie]

Nautilus crashes with an "assertion error" whenever accessing a folder, which is a symbolic link to a folder in another filesystem, and then deleting any file inside that folder (the file is not deleted).

Steps I used to reproduce de problem in my machine:

1) /dev/sda1 partition mounted on root folder with XFS filesystem;
2) /dev/sda2 partition mounted on /mnt/data folder partition with EXT4 filesystem;
3) create a folder "/mnt/data/test" and the empty text file "/mnt/data/test/file.txt";
4) in your home folder, create a symbolic to the "test" folder above with "ln -s /mnt/data/test";
5) open the symbolic link folder with "nautilus <home_folder>/test";
6) delete the "file.txt" file (pressing the delete button) and watch nautilus crashing with the following error:

nautilus: malloc.c:2909: __libc_malloc: Assertion `!victim || ((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x2) || ar_ptr == (((((mchunkptr)((char*)(victim) - 2*(sizeof(size_t)))))->size & 0x4) ? ((heap_info *) ((unsigned long) (((mchunkptr)((char*)(victim) - 2*(sizeof(size_t))))) & ~((2 * (4 * 1024 * 1024 * sizeof(long))) - 1)))->ar_ptr : &main_arena)' failed.
Abortado

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: nautilus 1:3.14.2-0ubuntu12
ProcVersionSignature: Ubuntu 4.2.0-17.20-generic 4.2.3
Uname: Linux 4.2.0-17-generic x86_64
ApportVersion: 2.19.1-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Oct 27 12:59:23 2015
GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where']"
InstallationDate: Installed on 2015-10-23 (3 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Rodrigo Renie (dmenor)]

Bug reported to the GNOME bugzilla:

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

[Sebastien Bacher (seb128)]

Thanks

[petersaints (petersaints)]

I don't think that this is nautilus specific. I have just tried to reproduce this on other file managers (e.g., nemo and thunar) and they also crash. The problem seems to be related with glib. So any file manager that relies on it will crash.

Can anyone confirm if my assertion is correct?

[petersaints (petersaints)]

On top of nautilus, nemo and thunar, I also found that pcmanfm and caja have the same problem. Dolphin, which doesn't rely on libglib2.0-0 is unaffected. The problem may actually be on some other depency that is shared by all these packages, but I think that libglib2.0-0 is the best bet.

I haven't confirmed if the problem is present on Xenial, which has a newer version of libglib2.0-0. If Xenial is unaffected, and the newer version doesn't break anything on Wily, I guess that all that has to be done is to backport it to Xenial.

I would really like that you would look closely into this bug. It is extremely annoying and very important in terms of user experience. I just don't consider it critical because it doesn't result in data loss, because if it did it would be disastrous.

[Launchpad Janitor (janitor)]

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

[Sebastien Bacher (seb128)]

in fact that's bug #1512826 which is fix commited (SRU done for wily and xenial waiting for the next upstream release)

[Launchpad Janitor (janitor)]

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

[Victor Passapera (vpassapera)]

I can confirm that the fix in the proposed package for bug #1512826 fixes this issue