View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003255 | Far Manager | Copy/Move | public | 2016-06-15 08:54 | 2016-09-26 16:30 |
| Reporter | pepak | Assigned To | DrKnS | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | x64 | OS | Windows | OS Version | 7 |
| Product Version | 3.0 | ||||
| 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. | ||||
| Build | 4796 | ||||
|
|
Can't reproduce. 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. |
|
|
|
|
|
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. |
|
|
4796 |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-15 08:54 | pepak | New Issue | |
| 2016-06-15 09:11 | 2useven10 | Note Added: 0014607 | |
| 2016-06-15 09:31 | pepak | Note Added: 0014609 | |
| 2016-06-15 09:37 | pepak | Note Added: 0014610 | |
| 2016-06-15 09:57 | 2useven10 | Note Added: 0014611 | |
| 2016-06-15 10:01 | 2useven10 | Note Added: 0014612 | |
| 2016-06-15 10:14 | pepak | Note Edited: 0014610 | |
| 2016-06-15 10:27 | 2useven10 | Note Edited: 0014611 | |
| 2016-09-18 09:06 | pepak | Note Added: 0014771 | |
| 2016-09-24 15:01 | pepak | Note Added: 0014795 | |
| 2016-09-24 15:02 | pepak | File Added: bug0003255.zip | |
| 2016-09-24 15:04 | pepak | Note Added: 0014796 | |
| 2016-09-25 17:59 | DrKnS | Assigned To | => DrKnS |
| 2016-09-25 17:59 | DrKnS | Status | new => assigned |
| 2016-09-25 18:09 | DrKnS | Note Added: 0014802 | |
| 2016-09-25 18:09 | DrKnS | Status | assigned => feedback |
| 2016-09-26 13:00 | DrKnS | Note Added: 0014808 | |
| 2016-09-26 15:58 | pepak | Note Added: 0014809 | |
| 2016-09-26 15:58 | pepak | Status | feedback => assigned |
| 2016-09-26 16:30 | DrKnS | Build | => 4796 |
| 2016-09-26 16:30 | DrKnS | Note Added: 0014811 | |
| 2016-09-26 16:30 | DrKnS | Status | assigned => closed |
| 2016-09-26 16:30 | DrKnS | Resolution | open => fixed |
| 2016-09-26 16:30 | DrKnS | Fixed in Version | => 3.0 |
