Page 1 of 4
Better handling of junctions
Posted: 12 Nov 2011 23:53
by Marco
This week I managed to mirror all my XP environment to a 7 one (two entirely different machines, by the way). One thing I noticed is that 7 heavily relies on junctions to mantain backward compatibility with XP paths. For example, Opera's profile folder located in C:\Documents and Settings\Marco\Dati applicazioni\Opera in XP can be reached entering the very same path in WE in 7. Explorer arrives at the "real" folder, which is C:\Users\Marco\AppData\Roaming\Opera, resolving internally every junction, namely :\Documents and Settings to :\Users and \Dati applicazioni to \AppData\Roaming.
Sadly things don't work so smoothly in XYplorer: pasting the whole "XP path" in XY address bar running in 7 gives an error (location or item not found).
However, what I noticed is that going (copy-paste in address bar) to just C:\Documents and Settings works. Then if I double click in the list the Marco folder the resulting path becomes C:\Users\Marco. I assume that XYplorer can't handle paths with junctions in the middle (but looks like it is fine with a junction at the end).
Any chance you can enhance the path resolution algorithm to better support junctions?
It would be very important to me, since I keep using both XP and 7. I basically need to reach the same/corresponding destinations on the two systems, and don't want to have two catalogs, one for XP paths and the other for 7 ones.
Re: Better handling of junctions
Posted: 13 Nov 2011 00:03
by nas8e9
For the record: both your Windows versions are Italian?
I can't reproduce this, but does enabling Configuration > General > Show localized folder names, make any difference?
Re: Better handling of junctions
Posted: 13 Nov 2011 00:08
by Marco
Yes, both versions are Italian.
That option doesn't seem to make any difference.
You can't reproduce? What steps are you doing exactly?
Re: Better handling of junctions
Posted: 13 Nov 2011 00:18
by nas8e9
Marco wrote:Yes, both versions are Italian.
That option doesn't seem to make any difference.
You can't reproduce? What steps are you doing exactly?
That's a pity.
I should have been clearer: I only have English Windows versions to my disposal.
Re: Better handling of junctions
Posted: 13 Nov 2011 03:41
by Trasd
Marco wrote:...the "real" folder, which is C:\Users\Marco\AppData\Roaming\Opera
does not have spaces anywhere in the path, but
Marco wrote:C:\Documents and Settings\Marco\Dati applicazioni\Opera
does.
As I don't have access to 7 and have never used it (same with Italian), don't know if this matters or is even relevent, but will quotes help in this situation?
Re: Better handling of junctions
Posted: 13 Nov 2011 03:48
by nas8e9
Trasd wrote:Marco wrote:...the "real" folder, which is C:\Users\Marco\AppData\Roaming\Opera
does not have spaces anywhere in the path, but
Marco wrote:C:\Documents and Settings\Marco\Dati applicazioni\Opera
does.
As I don't have access to 7 and have never used it (same with Italian), don't know if this matters or is even relevent, but will quotes help in this situation?
There's something screwy even on English Windows: pasting
Code: Select all
C:\Documents and Settings\[username]\Downloads\
, with or without quotes, in the address bar gets me to C:\Documents and Settings\, but no further. Show junctions is enabled; with show junctions disabled, the address bar input isn't resolved at all, which I guess *is* according to spec.
Re: Better handling of junctions
Posted: 13 Nov 2011 04:06
by Trasd
nas8e9 wrote:There's something screwy even on English Windows: pasting
Code: Select all
C:\Documents and Settings\[username]\Downloads\
, with or without quotes, in the address bar gets me to C:\Documents and Settings\, but no further. Show junctions is enabled; with show junctions disabled, the address bar input isn't resolved at all, which I guess *is* according to spec.
What about typing, pasting, or using the environment variable directly, this works for me (%username%, or %appdata%, etc., followed by "download" or whatever folder you are going for),
listed here for Win 7?
BTW, "C:\Documents and Settings\[username]\Downloads\" works fine on XP nas, not sure which OS you are running.... I have to assume you are using the English version of 7, so my experimentations won't help anyway.
Oh well, I was hoping to make a suggestion that might clear this up, but as I cannot try any of this on a Win 7 machine, I will bow out before I embarrass myself too much
!
Re: Better handling of junctions
Posted: 13 Nov 2011 10:48
by Marco
What about typing, pasting, or using the environment variable directly, this works for me (%username%, or %appdata%, etc., followed by "download" or whatever folder you are going for),
listed here for Win 7?
BTW, "C:\Documents and Settings\[username]\Downloads\" works fine on XP nas, not sure which OS you are running.... I have to assume you are using the English version of 7, so my experimentations won't help anyway.
Oh well, I was hoping to make a suggestion that might clear this up, but as I cannot try any of this on a Win 7 machine, I will bow out before I embarrass myself too much
!
I don't think it's a problem with language, as nas8e9 can reproduce the same mine behaviour behaviour on his English system. Nor should be spaces the problem.
From what I see, given a path, XY reads every "piece" between slashes, and goes to the folder, sequentially. When it finds a junction it doesn't simply read it, rather it executes that going to it's target, a real location. At this point the previous part of the path has changed, compared to the original input, and XY stops every further processing, remaining stuck in the middle.
It would be great if XY processed junctions in a different way, a-là Explorer.
PS: environment variables wouldn't solve the problem. Ok, I use them quite a lot, but there're scenarios in which I need the whole path.
Re: Better handling of junctions
Posted: 13 Nov 2011 13:36
by nas8e9
Trasd wrote:nas8e9 wrote:There's something screwy even on English Windows: pasting
Code: Select all
C:\Documents and Settings\[username]\Downloads\
, with or without quotes, in the address bar gets me to C:\Documents and Settings\, but no further. Show junctions is enabled; with show junctions disabled, the address bar input isn't resolved at all, which I guess *is* according to spec.
What about typing, pasting, or using the environment variable directly, this works for me (%username%, or %appdata%, etc., followed by "download" or whatever folder you are going for),
listed here for Win 7?
That does work, but through a different mechanism and at least visually, gets you in a virtual folder rather than the physical one. I saw from the OP's latest post that environment variables don't fully work for him.
Trasd wrote:BTW, "C:\Documents and Settings\[username]\Downloads\" works fine on XP nas, not sure which OS you are running.... I have to assume you are using the English version of 7, so my experimentations won't help anyway.
Windows 7 x64 SP1 English, which I should have mentioned.
Trasd wrote:Oh well, I was hoping to make a suggestion that might clear this up, but as I cannot try any of this on a Win 7 machine, I will bow out before I embarrass myself too much
!
I was pretty much a forum novice when I started out here. Trust me when I say that I still need to call frequently on a certain smilie...
Re: Better handling of junctions
Posted: 13 Nov 2011 19:37
by Trasd
nas8e9 wrote:I was pretty much a forum novice when I started out here. Trust me when I say that I still need to call frequently on a certain smilie...
Forum novice? Oh God no, XYplorer novice, yep.
Been using forums since before forums were around (figure that one out!). LOL
Re: Better handling of junctions
Posted: 14 Nov 2011 16:13
by Marco
Well, now we just need Don to read here...
Re: Better handling of junctions
Posted: 06 Dec 2011 11:29
by admin
OK, I have read it.
This is complex.
Win7 Explorer does not allow to browse the junction C:\Documents and Settings\, but XYplorer does. This is only possible because XY does not resolve the junction in the tree. If such a junction would be resolved, certain folders would end up in endless recursions because Win7 uses recursive junctions (hell knows why) in some places.
There are other factors to it I have no time to explain now. The downside is that certain paths (that contain partly junctions) cannot be resolved via the tree (which happens to be the normal way XYplorer works: first tree, then list). If you turn the Tree off (-> Lock Tree) the problem goes away, and the list will show the path you pasted into address bar. Could you try that, please?
Re: Better handling of junctions
Posted: 06 Dec 2011 12:04
by nas8e9
admin wrote:If you turn the Tree off (-> Lock Tree) the problem goes away, and the list will show the path you pasted into address bar. Could you try that, please?
After locking the Tree, the List does correctly resolve C:\Documents and Settings\[username]\Downloads\ to the physical location.
By way of a stupid question, it wouldn't be possible to special-case resolving of paths starting with C:\Documents and Settings\?
XYplorer 10.60.0118 / Windows 7 x64 SP1 English.
Re: Better handling of junctions
Posted: 06 Dec 2011 12:09
by admin
nas8e9 wrote:admin wrote:If you turn the Tree off (-> Lock Tree) the problem goes away, and the list will show the path you pasted into address bar. Could you try that, please?
After locking the Tree, the List does correctly resolve C:\Documents and Settings\[username]\Downloads\ to the physical location.
By way of a stupid question, it wouldn't be possible to special-case resolving of paths starting with C:\Documents and Settings\?
XYplorer 10.60.0118 / Windows 7 x64 SP1 English.
Only at the price of having an async state between unlocked tree and list, and the price for that has been 10,000 GBP once (for a user that has been tricked to fatal decisions by such a situation). I don't want to see this again.
Re: Better handling of junctions
Posted: 06 Dec 2011 12:13
by nas8e9
admin wrote:Only at the price of having an async state between unlocked tree and list, and the price for that has been 10,000 GBP once (for a user that has been tricked to fatal decisions by such a situation). I don't want to see this again.
I think I remember that thread; point taken.