After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656186 - Trash backend becomes unsuable when there are non-UTF-8 filenames.
Trash backend becomes unsuable when there are non-UTF-8 filenames.
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: trash backend
1.8.x
Other Linux
: Normal major
: ---
Assigned To: Allison Karlitskaya (desrt)
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2011-08-08 23:32 UTC by Hong Jen Yee
Modified: 2013-11-08 05:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
trash: Support enumerating non-UTF-8 filenames (1.50 KB, patch)
2013-11-05 08:58 UTC, Ross Lagerwall
accepted-commit_now Details | Review
trash: Add " (invalid encoding)" to files with invalid encoding (1.18 KB, patch)
2013-11-05 08:58 UTC, Ross Lagerwall
reviewed Details | Review
trash: Add " (invalid encoding)" to files with invalid encoding (1.23 KB, patch)
2013-11-07 15:35 UTC, Ross Lagerwall
accepted-commit_now Details | Review

Description Hong Jen Yee 2011-08-08 23:32:29 UTC
I noted that trash backend stops working after I trashed some files with non-UTF-8 filenames. It's unable to do dir listing, but this is only the case when display-name attribute is involved.

How to reproduce the bug:
1. Trash several files and folders with non-UTF-8 filenames.
2. Execute `gvfs-ls -l -a "standard:display-name" trash:///` or with `-a "standard::*"`.
3. You will notice that nothing are listed.
4. Execute `gvfs-ls -l trash:///` instead without "display-name" and compare the result with previous one. This one should work.

How to reproduce the bug, part 2:
1. Run nautilus
2. Go to trash can
3. Nothing will be shown, but there are actually several trashed files and folders.

How to reproduce the bug, part 3:
1. Try to gvfs-rm one of the files listed under trash:/// with non-UTF-8 filename.
2. The delete operation fails sometimes and the error message indicates "file not found".

I consider this a serious bug since you are not able to recover trashed files with non-UTF-8 filenames. For users who doesn't know xdg trash spec and ~/.local/share/Trash, this means "data loss" and a broken trash can.

Please fix this issue. Thanks a lot.
Comment 1 Ross Lagerwall 2013-11-05 08:58:00 UTC
Created attachment 258991 [details] [review]
trash: Support enumerating non-UTF-8 filenames

Before when enumerating, display names were set directly from the
filenames which can be a problem if the filename is not UTF-8.
Instead, don't set the display name at all since it is set correctly via
trash_backend_add_info().
Comment 2 Ross Lagerwall 2013-11-05 08:58:05 UTC
Created attachment 258992 [details] [review]
trash: Add " (invalid encoding)" to files with invalid encoding

Set the display name using the same method as for sftp and local files.
Comment 3 Ondrej Holy 2013-11-07 15:19:43 UTC
How can I make non-utf-8 filename? I have tried:
$ touch `echo -e "\x80\x81\x82"` 

...which produces invalid filename, however it doesn't cause any mentioned problems. Nautilus shows "[Invalid UTF-8]" and gvfs-ls trash:// shows "???" and erasing is possible.
Comment 4 Ondrej Holy 2013-11-07 15:20:08 UTC
Review of attachment 258992 [details] [review]:

It looks good, however untested. It would be better to use existing function for it:

gvfs_file_info_populate_names_as_local from gvfsdaemonutils.c
Comment 5 Ondrej Holy 2013-11-07 15:20:57 UTC
Review of attachment 258991 [details] [review]:

Looks good, however untested as the previous one.
Comment 6 Ross Lagerwall 2013-11-07 15:30:38 UTC
This broke it for me:
echo test > `echo -e "\x80\x81\x82\x83\x84\x85"`

I will update the second patch using gvfs_file_info_populate_names_as_local().
Comment 7 Ross Lagerwall 2013-11-07 15:35:05 UTC
Created attachment 259199 [details] [review]
trash: Add " (invalid encoding)" to files with invalid encoding
Comment 8 Ondrej Holy 2013-11-07 16:54:59 UTC
Review of attachment 259199 [details] [review]:

Looks good.
Comment 9 Ross Lagerwall 2013-11-08 05:00:24 UTC
Pushed to master as 15d5da3f13f9325cab8d32316304ce49d0ff83fb. Thanks!