Directory rename is broken

[e673]

Version: Far 2.3.211205-9d9c367f-alpha (build 21/12/05-9d9c367f-alpha) Linux x86_64
OS: Linux arch 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux

Way to reproduce:

1. Create directory A.
2. Create subdirectories B and C inside A.
3. Navigate to directory A and rename it (F6, Shift+F6) to D.

Expected result: A is renamed to D (like mv A D)

Actual result: new directory D is created, directory B is moved from A to D, directory C remains in A.

[unxed]

possibly related issue: https://t.me/far2l_ru/1093

[elfmz]

Funy bug, it happened only due to top-level dir was single char, if it would be something like mkdir -p AA/B AA/C then everything worked fine, thats why it was not noticed so long time
@unxed not related and actually not reproducible for me, although there were bugs like that in the past but already fixed. Can you ask which version they used?

[flowswitch]

V2.3 9d9c367.
My test sequence:

• copy kernel source tree to /tmp/aaa/
• rename aaa to bbb (F6, bbb, enter)
• the operation takes ~3sec, I can see a progress bar and file names being moved
• in contrast, mv aaa bbb works instantly

[elfmz]

Ah, its not what it looks like :)
First of all, if you'll change With symlinks combobox from 'Smartly ...' to 'Always copy link' it will also work instantly.
But this doesn't mean that smart symlinks copy disables moving. With this option directories need to be traversed to check for possible symlinks inside and also directories are created one-by-one but files inside of them are still moved instantly, but not copied/removed.

[flowswitch]

Haha, I was suspecting some setting but was looking in a wrong place (Options->System settings, where the "Use system copy routine" was in Windows version). But after reading your explanation and the builtin help (finally) I'm happy to leave it as is. Thanks for the explanation and sorry for false alarm :)