Situation - Using Gnome-Accounts and GVFS to mount a Google Drive. On copying a file from the remote GVFS filesystem, the filenames are turned into incomprehensible strings, taken from Google's internal ID used to distinguish identically-named files. Distribution : Manjaro Thunar: 1.8.4git-771dc2 gnome-control-center 3.32.1-1 gvfs 1.40.1-2 gvfs-google 1.40.1-2 gvfs-goa 1.40.1-2 gnome-online-accounts 3.32.0-1 To reproduce: 1. install gnome-control-centre, google-gvfs and gnome-online-accounts, 2. Use `sh -c "XDG_CURRENT_DESKTOP=GNOME gnome-control-center"` to add a Google account 3. Mount Google drive in Thunar and open it 4. Copy a file from Google Drive to a local file system 5. Notice the name of the copied file is nothing like the name of the file as correctly shown in Thunar, eg, copying a file named "my.vimrc" to my home directory resulted in a file named "19K-XUZfXa3V_BZEK<redacted>_6lclt" As per https://developer.gnome.org/gio/stable/GFile.html#GFile.description: > All GFiles have a basename (get with g_file_get_basename()). These names are byte strings that are used to identify the file on the filesystem (relative to its parent directory) and there is no guarantees that they have any particular charset encoding or even make any sense at all. If you want to use filenames in a user interface you should use the display name that you can get by requesting the G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME attribute with g_file_query_info(). This is guaranteed to be in UTF-8 and can be used in a user interface. But always store the real basename or the GFile to use to actually access the file, because there is no way to go from a display name to the actual name. Clearly, Thunar is accessing this G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME when displaying files in the UI, but on copying, it is instead using the byte string instead of ensuring that the copied file ends up represented to the user the same way.
Thanks for reporting ! Thunar is using "g_file_copy" to copy files (See ttj_copy_file in thunar-transfer-job.c) Possibly it would help to set G_FILE_COPY_ALL_METADATA as copy_flag. Could you check if that helps ? I dont have time to test this myself in detail currently ... will put it on my list (though my list already is very long). If you can, please feel free to debug yourself ! I dont know if we should always copy all metadata .. to be checked what that would mean. Can you reproduce the problem as well with nautilus ? (There is the chance that gvfs or google-gvfs is to blame )
> Possibly it would help to set G_FILE_COPY_ALL_METADATA as copy_flag. Could you check if that helps ? I'm not aware how to do that. and have not looked at the code at all. > Can you reproduce the problem as well with nautilus ? (There is the chance that gvfs or google-gvfs is to blame ) Sorry, should have said that I tested using Nautilus, and it copies the files across making the copied filename the G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME instead of the ID. Using Nautilus, I do not experience the same problem, thus I believe the issue is with Thunar, since both Thunar and Nautilus are using the same GVFS libraries as far as I know. I think the direction to maintain the attributes is within the GVFS filesystem, perhaps? Thunar's internal representation of the file object should use the ID, and that should be used when interacting with the GVFS remote system. But in order to maintain the displayed filename when copying to a non-GVFS filesystem, the display name needs to be used for the filename, since in local filesystems, they are the same thing. I'm making some assumptions based on general knowledge rather than any specific knowledge of GFile or Thunar code.
Just checked the nautilus code. No suprise, it as well uses "g_file_copy". Just like thunar it does not make use of G_FILE_COPY_ALL_METADATA However after copy, in nautilus there is a check "handled_invalid_filename", which possibly could make the difference: https://gitlab.gnome.org/GNOME/nautilus/blob/master/src/nautilus-file-operations.c#L5279
ops, should use permalink instead of pointing to master which might change: https://gitlab.gnome.org/GNOME/nautilus/blob/326fa60685f165ab74a09ac9c53f53a5b30fd66d/src/nautilus-file-operations.c#L5279
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/244. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev