Created attachment 5581 trivial symlink retry patch This Q&A describes the situation pretty well: http://askubuntu.com/questions/214562/cannot-transfer-file-due-to-filesystem-does-not-support-symbolic-links-error Basically, new Linux users are not very familiar with symlinks. When confronted with them, they often lead to catastrophic usability failures as described above, which are best answered as "that is a symlink, you need to find the target by hand and copy *that*", which basically a technical support nightmare. Even worse, some software extensively use symlinks. For example, git-annex uses symlinks to ensure data protection, but this breaks down usability for the joe user. Example story: http://git-annex.branchable.com/forum/usability:_what_are_those_arrow_things__63__/ Now, maybe we can blame git-annex for being a little exotic -- and there are workarounds on that side -- but I believe we can do better than that. There are some pretty well designed merge algorithm in Thunar that allow use to keep directories in sync. (That they could be improved with stuff like rsync is beyond the point here.) Why couldn't we do similar things with symlinks? What I am thinking of is instead of popping the user with what is basically an "Abort / Retry / Fail" UI... https://en.wikipedia.org/wiki/Abort,_Retry,_Fail%3F ... we could instead prompt the user with something like "Filesystem does not support symlinks, do you want to copy the symlink target instead? This may take up more space than the original." Attached is an untested patch to thunar that will actually retry without the "nofollow" flag (I *think*, my C is definitely rusty). Now I understand this is a rather drastic patch, and only fixes part of the problem - the user should probably be prompted here instead (but I don't know how to do that exactly). Furthermore, to fix this would probably require fixing it in other file managers as well (Nautilus suffers from the same issue), but I wanted to start the discussion somewhere, and Thunar is the file manager I use right now. Thanks for any feedback.
Created attachment 5582 same, but with progress information fixed the previous patch actually worked! but the progress is all screwed up, the attach patch tries to fix the byte count, but really, this is the wrong place to do things. the right place would probably be thunar_transfer_job_copy_node, where confirmation dialogs are popped up. but i'm too tired to reroll now. also, because this is done too low in the stack, out of disk conditions can occur and will freeze thunar. so not good.
*** Bug 11259 has been marked as a duplicate of this bug. ***
-- 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/84. 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