XYplorer Beta Club

Posted: **20 Dec 2011 10:01**

Thanks for the quick fix, now it works perfectly.
Well, probably the tweak on XP isn't as fundamental as on 7, since in this case you can reach the final destination. However:
1. as the philoshopy of XY is showing what's physically where, pointing to a physical destination through a physical path seems a natural and logical extension;
2. (my previous problem) having junctioned paths which point to outer volumes treated as if pointing to the system volume caused all the deletions performed to outer volumes to be executed with a transfer of data from the external disks to the recycle bin of the internal disk, with enormous waste of time. Plus some other misbehaviours which are totally expected but are frustrating.
So I totally welcome this tweak

Posted: **20 Dec 2011 10:14**

Thanks for the feedback.

I would be ready to elevate the tweak to GUI level and even promote it as cool feature but it looks like you and nas8e9 are the only ones using it...

Posted: **20 Dec 2011 12:01**

I have the feeling that lots of people use XY without being active on this forum. So maybe there're other people who will find it useful.
If I were you, I'd elevate it to the GUI and maybe give it a one-line mention on the 10.70 release notes.
Nothing bad could happen, right?

Posted: **20 Dec 2011 15:05**

Marco wrote:I have the feeling that lots of people use XY without being active on this forum. So maybe there're other people who will find it useful.
If I were you, I'd elevate it to the GUI and maybe give it a one-line mention on the 10.70 release notes.
Nothing bad could happen, right?

Too late now. I'll probably put it to 10.80.

Posted: **04 Feb 2012 11:10**

Just an update:
I found that the junctions troubling me were all the ones preset by Windows 7. Those junctions have the ACL set so that they cannot be opened by anyone, yet they can be traversed ( http://pherricoxide.wordpress.com/2009/ ... d-problem/ ). This is the reason of the errors that made me open this topic.

Now, thanks to a new feature brought by 10.80.0107, given a tab pointing to any location I can extract the real, physical destination path by running this script

Code: Select all

$destination="";
$origin="<curpath>";
$i=1;
$piece=gettoken("$origin",$i,"\");

while ("$piece"!="") {
    $destination="$destination"."$piece"."\";
    while (property("#junctiontarget","$destination")!="") {
       $destination=property("#junctiontarget","$destination")."\";
    };
    $piece=gettoken("$origin",$i++,"\");
};

Even if they're different things, the advantage over to the tweak mentioned in the previous posts is that junctions pointing to other junctions are immediately resolved, due to the second while loop.
Despite the nested loops execution is pretty fast even on a 6.5 years old machine.

My personal suggestion: junctions are mainly made to shorten paths or create identical paths on different machines pointing to "corresponding" locations (XP and 7 are an example). By creating junctions with a "normal" ACL (not like the one described above) XY will never show any browsing error. Should the real path be needed, it can quickly be obtained with the script above.

I hope this helps.

Posted: **04 Feb 2012 11:20**

Your function is pretty identical to the tweak (ResolveNestedJunctions). Do you get different results compared to the tweak?

FYI, you need not quote variables.

Posted: **04 Feb 2012 11:31**

admin wrote:FYI, you need not quote variables.

Ah ok thanks, good to know.

Your function is pretty identical to the tweak (ResolveNestedJunctions). Do you get different results compared to the tweak?

Yes. Although my test involves quite a worst case scenario.
Steps:
1. Create a folder somewhere (for example New Folder in Desktop)
2. Create a junction to it, still in Desktop
3. Now create, still in Desktop, a junction to the junction
4. Now create a New Folder inside this last junction.

Real path of the last created folder: C:\Users\Marco\Desktop\New Folder\New Folder\
Path obtained by browsing to the last created junction and then inside the only folder in there (with tweak): C:\Users\Marco\Desktop\Junction to Junction to New Folder\New Folder\
Path obtained by pasting the above path in the AB (with tweak): C:\Users\Marco\Desktop\Junction to New Folder\New Folder\
Path obtained by pasting the above path in the AB (with tweak): C:\Users\Marco\Desktop\New Folder\New Folder\

Posted: **04 Feb 2012 11:40**

The last two lines make no sense. Typo?

Posted: **04 Feb 2012 11:41**

No, recursion. Try it.

Posted: **04 Feb 2012 11:51**

Marco wrote:Path obtained by pasting the above path in the AB (with tweak): C:\Users\Marco\Desktop\Junction to New Folder\New Folder\
Path obtained by pasting the above path in the AB (with tweak): C:\Users\Marco\Desktop\New Folder\New Folder\

Hm, I don't get it: 2 identical conditions produce different results? Not in this universe.

Apart from that: I just fixed my ResolveNestedJunctions tweak routine so that it now also resolves junctions to junctions. So your script is now obsolete.

Thanks for the hint!

Posted: **04 Feb 2012 14:09**

admin wrote:FYI, you need not quote variables.

But *if* you do, you can write instead of
$destination="$destination"."$piece"."\";
$destination="$destination$piece\";

You can also write:
$destination=$destination$piece\;
(...just tested it.) But I would not really do: this might be illegal tomorrow, I think!

But back to the origin: a pure variable has no reason to be quoted, while a (double) quote may contain variables. Important: it must be possible for XY to distinguish the end of a variable name - this is by a character that isn't allowed in that name, e.g. '$' or '\'. If in the example '\' were 'x' this would not work:
$destination="$destination$piecex";

But of course you can chose the "most clean" versions:
$destination=$destination.$piece."\";
or if using some " " for "optical separation":
$destination = $destination . $piece . "\";

No doubt: do not insert " " inside quotes: they would be inserted into the string!
(Though they limit the end of variable names...)

Posted: **07 Mar 2012 22:49**

Seems like the #ResolveJunctions property doesn't work.

Posted: **08 Mar 2012 09:10**

Marco wrote:Seems like the #ResolveJunctions property doesn't work.

It currently only works if "Configuration | Advanced | Resolve junctions" is ON. This is a bug, of course. Fix comes.

Posted: **08 Mar 2012 17:20**

Thanks, now it works.
May I ask a last (I promise

) tweak to the code that extracts the destination path?
I suppose you read and maybe took inspiration from the code I posted above, this:

Code: Select all

$destination="";
$origin="<curpath>";
$i=1;
$piece=gettoken("$origin",$i,"\");

while ("$piece"!="") {
    $destination="$destination"."$piece"."\";
    while (property("#junctiontarget","$destination")!="") {
       $destination=property("#junctiontarget","$destination")."\";
    };
    $piece=gettoken("$origin",$i++,"\");
};

Could you make it so that, after the while loop is over, the whole code restarts and gets executed, until the result doesn't change anymore? I have a particular folder structure that needs the code to be executed twice in order to get the final path.
I was thinking to something like:

Code: Select all

$destination="";
$origin="<curpath>";
$i=1;
$piece=gettoken("$origin",$i,"\");

while loop_instance #1;

$origin=$destination;
reset $destination;
$i=1;
$piece=gettoken("$origin",$i,"\");

while loop_instance #2;

if "$destination from while loop_instance #2"=="$destination from while loop_instance #1" -> path found
else

$origin=$destination;
reset $destination;
$i=1;
$piece=gettoken("$origin",$i,"\");

while loop_instance #3;

etc etc

Posted: **09 Mar 2012 05:34**

But you'd still need another halt condition, infinite loops can arise.

XYplorer Beta Club

Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions

Re: Better handling of junctions