When pasting a directory into a directory that already contains a directory with the same name Thunar currently merges both directories without asking, it should instead ask whether to merge or to rename the pasted folder.
Please, I second this, it happened several times it merged when I did not intend to and then un-doing is a mess as there is no CTRL-Z like in Caja.
Looks like in recent thunar (at least version 1.8.10) the merge behaviour has disappeared and thunar now asks to replace the whole folder. When was this committed to the tree? Can someone point to a specific commit?
(In reply to Guido Falsi from comment #2) > Looks like in recent thunar (at least version 1.8.10) the merge behaviour > has disappeared and thunar now asks to replace the whole folder. > > When was this committed to the tree? Can someone point to a specific commit? Looks like what changed is the requester, using the word "replace" in the button. After telling it to replace directory contents are still merged.
I was also puzzled by new behaviour, to the point that I opened PR in FreeBSD's bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242142 As Guido said, at least on FreeBSD, clicking "replace" merges folders. I don't mind additional click to get the functionality I'm used to, although I would prefer the possibility to configure it "old way" or "new way", something like "do not warn when merging folders" in preferences. What I do mind is the confusion created by using word "replace". I am not native English speaker (although I take pride in my C2 certification), but "to replace" sounds like "put new in place of old". It's not exact "overwrite", but sounds more like "overwrite" than "put new to place of old, leaving old as well if there are no conflicts". I think prompt should offer "merge", "overwrite" and "and "cancel", and should be opt-in in preferences.
Thanks for reporting! Just checked, it is a side effect of this commit: https://git.xfce.org/xfce/thunar/commit/?h=xfce-4.14&id=db49aa728b029ca1c398d0d8bee9a41db0c399ce However for some reason my concrete observations seem to differ from yours: My setup: test/folder/file1 (some text inside) test/sub/folder/file1 (empty) test/sub/folder/file2 Using STRG+C /STRG+V to copy "test/sub/folder" into "test" gives me, like before, the possibility to merge. I am asked to overwrite on each file. Using DND or STRG+X /STRG+V to move "test/sub/folder" into "test" gives me, only the option to replace. No possibility to decide if single files are overwritten any more. file1 will be replaced by an empty one. That is what I would expect from the "replace" button I pressed. Do you see the same concrete behaviour on BSD, or something different ? That change in behavior actually is a direct result of the fix of Bug #15727 before a copy was performed when a folder already existed, leading to time consuming operations. Now the old folder is deleted an a move is performed instead. A merge is not foreseen in that scenario. Like before, it still would be nice to be asked to rename the existing folder, like this bug suggests.
Possibly it would be nice to have an additional "merge" button on move, which could, like before, do a copy and than deletes the origin.
(In reply to alexxcons from comment #5) > Do you see the same concrete behaviour on BSD, or something different ? I haven't done any thorough tests, just my use case, which never involves files of the same name, just folders of the same name with files of different names. IIRC warning about replacing _files_ existed before this change. But if there was no _file_conflicts, folders were silently merged. After the change, warning about replacing _folder_ happens, and - if there are no _file_ conflicts - it gets merged after clicking "replace". Hope this helps. I'd be glad to do further testing if needed.
(In reply to Marko Cupać from comment #7) > > IIRC warning about replacing _files_ existed before this change. But if > there was no _file_conflicts, folders were silently merged. Yes, exactly. That is still the case if you use CTRL+C and CTRL+V (copy) but not any more for CTRL+X and CTRL+V (move). Move will now ask you if it is fine to replace the folder. > After the change, warning about replacing _folder_ happens, Only for move, not for copy. >and - if there are no _file_ conflicts - it gets merged after clicking "replace". Negative, for me on "move", the folder is replaced, like the dialog says. Could you please re-test that use-case ?
-- 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/154. 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