View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003255||Far Manager||Copy/Move||public||2016-06-15 10:54||2016-09-26 18:30|
|Target Version||Fixed in Version||3.0|
|Summary||0003255: Content of symbolic links not copied|
|Description||In 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 Reproduce||1) 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 Information||The incorrect behavior appears in builds 4700 or 4634, but works fine in 4535.|
|Tags||No tags attached.|
4707 x64 win10 -- everything is ok.
||Tested on Windows 10 x64, works as described with the default configuration (only standard plugins, clean profile).|
Tested also on a clean installation of Windows 7 x64 with FAR build 4707.
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.
||it is result of preventing endless copy recursion...|
||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.|
||This is related to http://bugs.farmanager.com/view.php?id=3311 - 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.|
bug0003255.zip (6,080 bytes)
Attached files bug0003255.zip 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 http://bugs.farmanager.com/view.php?id=3311 must also be applied.
Question: in your patch, what's the following line for:
ScanItems.back() here is the upper directory, what's the point in inheriting its links?
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.
||I see, thanks. 'ActiveLinks' name is little confusing though.|
|2016-06-15 10:54||pepak||New Issue|
|2016-06-15 11:11||2useven10||Note Added: 0014607|
|2016-06-15 11:31||pepak||Note Added: 0014609|
|2016-06-15 11:37||pepak||Note Added: 0014610|
|2016-06-15 11:57||2useven10||Note Added: 0014611|
|2016-06-15 12:01||2useven10||Note Added: 0014612|
|2016-06-15 12:14||pepak||Note Edited: 0014610||View Revisions|
|2016-06-15 12:27||2useven10||Note Edited: 0014611||View Revisions|
|2016-09-18 11:06||pepak||Note Added: 0014771|
|2016-09-24 17:01||pepak||Note Added: 0014795|
|2016-09-24 17:02||pepak||File Added: bug0003255.zip|
|2016-09-24 17:04||pepak||Note Added: 0014796|
|2016-09-25 19:59||DrKnS||Assigned To||=> DrKnS|
|2016-09-25 19:59||DrKnS||Status||new => assigned|
|2016-09-25 20:09||DrKnS||Note Added: 0014802|
|2016-09-25 20:09||DrKnS||Status||assigned => feedback|
|2016-09-26 15:00||DrKnS||Note Added: 0014808|
|2016-09-26 17:58||pepak||Note Added: 0014809|
|2016-09-26 17:58||pepak||Status||feedback => assigned|
|2016-09-26 18:30||DrKnS||Build||=> 4796|
|2016-09-26 18:30||DrKnS||Note Added: 0014811|
|2016-09-26 18:30||DrKnS||Status||assigned => closed|
|2016-09-26 18:30||DrKnS||Resolution||open => fixed|
|2016-09-26 18:30||DrKnS||Fixed in Version||=> 3.0|