Junctions not recognized on Move, source contents deleted

[ghisler(Author)]

What should TC do then? Just not follow the junctions and do nothing? Just copy the files?

[JudgeAxl]

I would prefer if there was an option to follow symlinks or not. Unix flavors, which have used links a lot longer than Windows, offer options to both 'cp' and 'mv' (and similar commands) allowing one to choose how links should be treated.

There's however a difference in how unix expects links to be handled if the source is the actual link compared to if the links are contained in the folder being copied.

IMHO, links are a tricky matter and for most Windows users it's a rather new thing that require some education. To learn from unix is probably not a bad idea here.

And since I noticed that the discussion got a bit heated earlier, I personally only want to make sure TC keeps it's position as the best file manager out there. I've been using it for over 10 years and it's always the first thing that gets installed on all my machines. I've gotten all my employers to buy licenses as well.

/axl

[icfu]

What should TC do then? Just not follow the junctions and do nothing? Just copy the files?

JunctionMove=0/1/2/3
0=Ask (Default action: Move junction)
1=Don't ask but move junction
2=Don't ask but copy junction target
3=Don't ask but move junction target (current behaviour)

Icfu

[StatusQuo]

JunctionMove=0/1/2/3

Support.

Option 2 would be most logical for me:
2=Don't ask but copy junction target (then delete junction)

This "moves" D:\junction\*.* without altering D:\original\*.*

[icfu]

Nope, this a misunderstanding. With "junction target" I mean the target directory which the junction points to, and in the junction target you find the source files...

So, what you want is option 1.

Icfu

[JudgeAxl]

This sounds like it could get messy, let's write a couple of use cases to clarify for everyone:

Given:
C:\real\bar\file.txt
C:\foo\real(->c:\real)\bar\file.txt

Move folder C:\foo to D:\ without following links
Then:
C:\real\bar\file.txt
D:\foo\real(->c:\real)\bar\file.txt

Move folder C:\foo to D:\ and follow links
Then:
C:\
D:\foo\real\bar\file.txt

Copy folder C:\foo to D:\ without following links
Then:
C:\real\bar\file.txt
C:\foo\real(->c:\real)\bar\file.txt
D:\foo\real(->c:\real)\bar\file.txt

Copy folder C:\foo to D:\ and follow links
Then:
C:\real\bar\file.txt
C:\foo\real(->c:\real)\bar\file.txt
D:\foo\real\bar\file.txt

Additional cases for when the junction itself is moved perhaps?

/axl

[StatusQuo]

2icfu

JunctionMove=0/1/2/3
0=Ask (Default action: Move junction)
1=Don't ask but move junction
2=Don't ask but copy junction target
3=Don't ask but move junction target (current behaviour)

2=Don't ask but copy junction target (then delete junction)

This "moves" D:\junction\*.* without altering D:\original\*.*

Nope, this a misunderstanding. With "junction target" I mean the target directory which the junction points to, and in the junction target you find the source files...

Well, so do I, and I would interpret option 2 to
- copy all source files found in the target directory which the junction points to
- then delete the junction itself

=> result:
- the files previously found under the junction are now on the target of the move action (USB harddisk)
- the "moved" junction is not there anymore (deleted after copying)
- the original files (in the directory which the junction points to) have not changed at all

So TC would behave exactly like moving a normal directory (containing a 1:1 copy of the files in the junction target directory).

This is option 2, isn't it?
I'd understand option 1 to just create a junction at the move target - resulting in a junction on the USB harddisk, pointing to the local harddisk.

[StatusQuo]

2JudgeAxl

Additional cases for when the junction itself is moved perhaps?

Well, with the options suggested by icfu you could let TC ask you for every case or let it always move the junction, or let it always copy the data...

[icfu]

This is option 2, isn't it?
I'd understand option 1 to just create a junction at the move target - resulting in a junction on the USB harddisk, pointing to the local harddisk.

Indeed, you are right! I had misunderstood you, not vice versa... Looks like we share the same opinion, very nice!

Icfu

[JudgeAxl]

2JudgeAxl

Additional cases for when the junction itself is moved perhaps?

Well, with the options suggested by icfu you could let TC ask you for every case or let it always move the junction, or let it always copy the data...

True, but having developed software for the last 25 years, I know it's a rare moment when everyone understands exactly how "the customer" expect things to work. :)

[ghisler(Author)]

So it seems that the best solution would be to copy the data from within the junction, and then delete the junction itself, right?

[StatusQuo]

So it seems that the best solution would be to copy the data from within the junction, and then delete the junction itself, right?

Yes, I think so.

P.S.: Only when moving through renaming isn't possible, of course, like moving to a different drive.

[Rob Weinstein]

I suggest that when TC moves a junction, it just moves the junction itself, none of the files are copied or moved. In other words, create a new junction at the destination path and remove the original junction. I think this is how the command interpreter works (at least when the junction is moved to the same drive). The command interpreter gives "access denied" when I try to move a junction to a different drive letter.

I think Icfu's option scheme is the way to go.

[ghisler(Author)]

I suggest that when TC moves a junction, it just moves the junction itself, none of the files are copied or moved. In other words, create a new junction at the destination path and remove the original junction.

Hmm, I'm not sure that this is such a good idea: If the junction points to a different branch of the copied directory tree, then it will point into nowhere after the move has completed. Also making such a junction pointing somewhere else on an external NTFS drive will make the user think that the data was backed up, while he only sees a link to the data.

[StatusQuo]

I suggest that when TC moves a junction, it just moves the junction itself

On the same drive this is already the case and perfectly OK with me (TC just renames here).
But normally not for different drives. This would be an argument for a configurable option and/or the "ask user" option, IMO.

0=Ask (Default action: Move junction)

An additional checkbox "Apply the selected action to all junctions" (during the current operation) would be nice for this option.
As stated above I'd prefer another default, but I probably wouldn't mind, if the actions will have accelerator keys.


BTW, for moving on the same drive:
I would have expected problems when TC can't rename a locked directory structure
and moves the contained data instead, but I didn't find a scenario yet where this is the case
(applications like CMD or Office seem to lock the original path, not the junction path, even if a file is opened via the junction path).

If the junction points to a different branch of the copied directory tree, then it will point into nowhere after the move has completed.

Hm, yes, this sounds like a technical problem with just moving a junction, like

Code: Select all

D:\dir\drv\network\vendor
D:\dir\vendor-junction     (pointing at the above)

When moving D:\dir to E:\dir junctions like the above probably would have to be analyzed and modified in such cases to be of any use.

Edit:
Maybe the danger of junctions pointing to nowhere is in the nature of junctions,
so TC should not have to worry about that?
Because if in the above example the user renames D:\dir to D:\new, the contained junction gets invalid, too.
And also *.lnk don't get updated, when their target gets renamed/moved.