View Issue Details

IDProjectCategoryView StatusLast Update
0003255Far ManagerCopy/Movepublic2016-09-26 15:30
Reporterpepak Assigned ToDrKnS  
Status closedResolutionfixed 
Platformx64OSWindowsOS Version7
Product Version3.0 
Fixed in Version3.0 
Summary0003255: Content of symbolic links not copied
DescriptionIn recent versions of FAR 3, the content of symbolic links is not being copied when the "Copy contents of symbolic links" is checked.
Steps To Reproduce1) Create directory "test"
2) In "test", create subdirectory "1"
3) In "test", create a symbolic link to "1" named "2" (link type: junction)
4) In "test\1", create a file "test.txt" with any content.
5) Attempt to copy "test" to a "temp" directory, with "Copy contents of symbolic links" checked.

Expected result: In "temp", there will be directories "test", "test\1", "test\2" and files "test\1\test.txt" and "test\2\test.txt".

Actual result: In "temp", there will directories "test", "test\1", "test\2" and the file "test\1\test.txt". File "test\2\test.txt" is not present, and any other content of the "test\2" directory will be missing - if "test\2" is a junction, the directory will be created but the other content will be skipped.
Additional InformationThe incorrect behavior appears in builds 4700 or 4634, but works fine in 4535.
TagsNo tags attached.



2016-06-15 08:11

developer   bugnote:0014607

Can't reproduce.
4707 x64 win10 -- everything is ok.


2016-06-15 08:31

reporter   bugnote:0014609

Tested on Windows 10 x64, works as described with the default configuration (only standard plugins, clean profile).


2016-06-15 08:37

reporter   bugnote:0014610

Last edited: 2016-06-15 09:14

Tested also on a clean installation of Windows 7 x64 with FAR build 4707.


2016-06-15 08:57

developer   bugnote:0014611

Last edited: 2016-06-15 09:27

reproduced. i didn't repeat your scenario exactly...
it doesn't work when files/directories already copied in the same operation.
actually depending on sources scan order link can be copied instead of the real directory.


2016-06-15 09:01

developer   bugnote:0014612

it is result of preventing endless copy recursion...


2016-09-18 08:06

reporter   bugnote:0014771

Apparently fully fixing this is difficult, or at least too difficult to be worth it, but would it be possible to e.g. add a far:config setting to not involve "preventing endless copy recursion"? I am not very concerned about endless recursion, but I run into problems with "copy content of symbolic links" regularly :-(. If I had any idea where to look, I would (try to) fix it myself, but I don't.


2016-09-24 14:01

reporter   bugnote:0014795

This is related to - the infinite recursion protection is responsible for the case described above, but some other cases of incorrect skipping of directories are caused by a bug in pathmix.cpp.


2016-09-24 14:02

reporter (6,080 bytes)


2016-09-24 14:04

reporter   bugnote:0014796

Attached files contains a proposed fix for this issue. I believe it covers all the cases - if fixes the error described in the first message, and it still keeps infinite loop protection. All the loop cases I could think of work fine.

Note: In order to be fully effective, the patch from must also be applied.


2016-09-25 17:09

administrator   bugnote:0014802



2016-09-26 12:00

administrator   bugnote:0014808

Question: in your patch, what's the following line for:

Data.ActiveLinks = ScanItems.back().ActiveLinks;

ScanItems.back() here is the upper directory, what's the point in inheriting its links?


2016-09-26 14:58

reporter   bugnote:0014809

That's what prevents the infinite loops. Imagine a structure like A\B\C with C being a link to A.

Strictly speaking, it's not necessary to have a new ActiveLinks set for each subdirectory, the same thing could be done with a single list, but it would require a much more careful handling of backtracking. I opted for an inefficient but simple solution.


And yes, I can confirm that 4796 works fine for my test cases.


2016-09-26 15:30

administrator   bugnote:0014811

I see, thanks. 'ActiveLinks' name is little confusing though.

Issue History

Date Modified Username Field Change
2016-06-15 07:54 pepak New Issue
2016-06-15 08:11 2useven10 Note Added: 0014607
2016-06-15 08:31 pepak Note Added: 0014609
2016-06-15 08:37 pepak Note Added: 0014610
2016-06-15 08:57 2useven10 Note Added: 0014611
2016-06-15 09:01 2useven10 Note Added: 0014612
2016-06-15 09:14 pepak Note Edited: 0014610
2016-06-15 09:27 2useven10 Note Edited: 0014611
2016-09-18 08:06 pepak Note Added: 0014771
2016-09-24 14:01 pepak Note Added: 0014795
2016-09-24 14:02 pepak File Added:
2016-09-24 14:04 pepak Note Added: 0014796
2016-09-25 16:59 DrKnS Assigned To => DrKnS
2016-09-25 16:59 DrKnS Status new => assigned
2016-09-25 17:09 DrKnS Note Added: 0014802
2016-09-25 17:09 DrKnS Status assigned => feedback
2016-09-26 12:00 DrKnS Note Added: 0014808
2016-09-26 14:58 pepak Note Added: 0014809
2016-09-26 14:58 pepak Status feedback => assigned
2016-09-26 15:30 DrKnS Build => 4796
2016-09-26 15:30 DrKnS Note Added: 0014811
2016-09-26 15:30 DrKnS Status assigned => closed
2016-09-26 15:30 DrKnS Resolution open => fixed
2016-09-26 15:30 DrKnS Fixed in Version => 3.0