Better handling of junctions

[admin]

What particular folder structure is that?

[Marco]

This is the folder structure I'm talking about:

Code: Select all

  C:\Dati\Condivisi\Musica\
                      |
                      |
C:\Backup\Condivisi\Musica\
     |
     |
     N:\Condivisi\Musica\

Now, I tried to end up with a possible code that should avoid multiple runs in cases like mine and should be resistant to loopy structures (the ones that may crash antivirus engines and backup programs).
The code is in XY scripting language and is based on the existance of the old #junctiontarget property which, as far as I could understand from its behaviour, examines the last directory of a path and checks if it has a reparse point attribute set and, if so, its target (by the way, I suppose that this is the information you have access to while writing in VB6).

Code: Select all

$destination="";								//initialize the variable containing the final, destination path
$destination_list="";						//initialize the variable containing the list of final, destination paths
$origin="<curpath>";						//get and set the original, current path
$i=1;											//initialize the token counter to 1
$piece=gettoken("$origin",$i,"\");	//get and set the first (from $i=1) part (probably a drive letter) of the original path

while (1==1) {								//just a way to start a sure loop
	while ("$piece"!="") {									//operate until there is nothing more after the last slash
		$destination="$destination"."$piece"."\";										//on the first run this loop gets the drive letter and checks whether it is a junction pointing to somewhere					(cont.)
		while (property("#junctiontarget","$destination")!="") {					//(it shouldn't be possible btw afaik), building the first part of the final path, then it appends the next part of the original path	(cont.)
			$destination=property("#junctiontarget","$destination")."\";			//in order to form an embryo of the final path, and again the existance of a junction point is checked						(cont.)
		};																							//whenever a reparse point is found $destination gets the junction target plus a slash as value, discarding the previous content
		$piece=gettoken("$origin",$i++,"\");									//get and set the following part (probably a folder) of the original path
	};

	if strpos($destination_list,$destination,,)=="-1" {						//control if the destination found is present in the list of previously found destinations		(cont.)
		$destination_list="$destination_list"."<crlf>"."$destination";	//and if not it adds it to that list
	} else {																				//in case the obtained destination was already found previously we have a loopy folder		(cont.)
		break;																				//structure and we need to stop the loop execution and get out of it
	};

	$origin=$destination;						//set the found destination as new starting path
	$destination="";							//reset the variable containing the final, destination path
	$i=1;											//reinitialize the token counter to 1
	$piece=gettoken("$origin",$i,"\");	//get and set the first (from $i=1) part (probably a drive letter) of the new starting path
};

goto $destination;

I cannot test this code but afaics there shouldn't be major bugs. Should a loopy folder structure be present, this code would always return the same result path.
Since this could be not advisable, a method for getting different results upon code re-execution is prepending this line to the break:

Code: Select all

$destination=gettoken($destination_list,-1,<crlf>);

PS:I'm working on a 1920*1200 screen and I see on lower resolutions reading the code could be difficult, I attach a text file with it, hth.

[admin]

[quote="Marco"]This is the folder structure I'm talking about:

Code: Select all

  C:\Dati\Condivisi\Musica\
                      |
                      |
C:\Backup\Condivisi\Musica\
     |
     |
     N:\Condivisi\Musica\

Please make it more clear to ensure that I understand it right:
1. Which is the junction to which target?
2. What is the expected input and output of the #junctiontarget property?

[Marco]

Ok.
C:\Dati\Condivisi\Musica points to C:\Backup\Condivisi\Musica, and meanwhile C:\Backup points to N:\.

I would expect the property #junctiontarget to behave (in order to make the script above functional) in:
• input: a fully qualified path (drive_letter:\folder1\folder2\etc\), ending with a "\"
• output: a fully qualified path (drive_letter:\folder3\folder4\etc\), ending with a "\"
i.e. the behaviour of the "old" #junctiontarget.

[admin]

So you want C:\Dati\Condivisi\Musica to return C:\Backup\Condivisi\Musica?

Doesn't property("#JunctionTarget") do this?

[Marco]

Mmh, I wrote the long post late at night, maybe I haven't expressed all the concepts properly...

Your first attempt to resolve junctions and exposing the destination path was through the property #junctiontarget, which worked by examining the last folder of a path, looking for a reparse point attribute and, if present, outputting the target path. In practical words, #junctiontarget of C:\Dati\Condivisi\Musica would have given C:\Backup\Condivisi\Musica.

Then I pointed out that this method would have failed in presence of junctions in the middle of the path, thus #junctiontarget of C:\Dati\Condivisi\Musica\Van Halen - 1984 would have given again C:\Dati\Condivisi\Musica\Van Halen - 1984. Assuming that in VB6 the only information about junctions is whether a folder (just a folder) has a reparse point attribute and, if so, its value (i.e. the target), i suggested to tweak the algorithm for #junctiontarget as in http://www.xyplorer.com/xyfc/viewtopic. ... =30#p68696.

You did that and you also changed the name property to #resolvejunctions.

Now, what I'm suggesting is to tweak the code behind #resolvejunctions as in my last long post, so to obtain N:\Condivisi\Musica from C:\Dati\Condivisi\Musica. In the code I propose I use the old #junctiontarget so to mantain a sort of correspondence between the XY-syntax code and the VB6 code.

I hope I've been clearer this time, if not just let me know.

[admin]

Thanks, that was clearer. I think I got it now. See next version...

[Twisten]

I Propose that XYplorer keep track of interim results when using the multiple resolves method and throw an error or informational message if it encounters the same result more than once instead of leaving infinite loops possible.

[admin]

I Propose that XYplorer keep track of interim results when using the multiple resolves method and throw an error or informational message if it encounters the same result more than once instead of leaving infinite loops possible.

Yes, probably worth the trouble.

[Marco]

The code I proposed above does that in fact.
Meanwhile thanks Don, everything works smoothly and as expected so far!

[admin]

The code I proposed above does that in fact.
Meanwhile thanks Don, everything works smoothly and as expected so far!

Great. Next version has the cyclic death safety belt.