Open only checks exists when PFA fails.

[TheQwerty]

Currently when opening a file XY throws an error if the item/target does not exist before checking the PFA list.

This is unfortunate for a couple reasons:
1) Many programs can create a new file when passed a non-existent path. (i.e. notepad C:\newFile.txt) In general this might not be useful in XY since it's hard to double-click a non-existing item, but it could be nice for scripts which want to respect the user's associations. However, by failing early XY will never pass a non-existing path to a PFA match.

2) XY still being a 32-bit program means Windows resolves shortcuts containing %ProgramFiles% to the x86 directory, which often means the target cannot be found. Again by failing before the PFA the user cannot correct this behavior so that those shortcuts can actually be opened.


I propose that the exists test (or at least the error dialog) be moved such that:
- It occurs after the PFA list is checked.
- If no match is found then it checks if the item exists, and throws the error when it does not.
- Otherwise it's a PFA match and XY should only check that the associated program exists, not the item being passed to it.


As this may be a radical change I feel it might be appropriate (and don't mind) if this were buried in a tweak.

Thank you!

[admin]

I see your points, and will simply drop the text for existence.

As this may be a radical change I feel it might be appropriate (and don't mind) if this were buried in a tweak.

I don't think it's very radical. There are not many ways to pass a non-existing item to this function, and when you do this you do it on purpose.

[TheQwerty]

I don't think it's very radical. There are not many ways to pass a non-existing item to this function, and when you do this you do it on purpose.

To be honest, I agree. The change in functionality didn't seem too radical but to touch something that's been in place for quite a while... more-so.

[TheQwerty]

Hmph.. I thought that would allow me to work around this shortcut issue by injecting a script into the process of opening an invalid shortcut but no such luck.

With these PFAs:

Code: Select all

+lnk>::Echo 'Lnk: ' . <pfaitem>;
+exe>::Echo 'Exe: ' . <pfaitem>;
+*>::Echo 'All: ' . <pfaitem>;

Opening a valid shortcut (pointing to XY) gives me:
Lnk: C:\Users\...\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\XYplorer.lnk

Opening one of those redirected shortcuts (pointing to %ProgramFiles% and thus redirected to the x86 one) still gives me:

screenshot.20.png

Opening a shortcut pointing at an off-line network location opens a WE window and then pops up an error dialog stating:

\\server is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

The network address is invalid.

Thoughts?

[admin]

My thought is: These shortcuts are wrongly done. They should have used %ProgramW6432%. XY cannot fix this.

Quoting wikipedia:

%ProgramFiles%, %ProgramFiles(x86)%, %ProgramW6432%
The %ProgramFiles% variable points to the Program Files directory, which stores all the installed programs of Windows and others. The default on English-language systems is "C:\Program Files". In 64-bit editions of Windows (XP, 2003, Vista), there are also %ProgramFiles(x86)%, which defaults to "C:\Program Files (x86)", and %ProgramW6432%, which defaults to "C:\Program Files". The %ProgramFiles% itself depends on whether the process requesting the environment variable is itself 32-bit or 64-bit (this is caused by Windows-on-Windows 64-bit redirection).

[TheQwerty]

My thought is: These shortcuts are wrongly done. They should have used %ProgramW6432%. XY cannot fix this.

For what it's worth I agree, but I'm not about to start a crusade to correct all of their wrongdoings.

There's a lot of places to throw blame...
Those developers being lazy/ignorant and using %ProgramFiles%.
Microsoft not providing a way to disable the redirection or get the unresolved target without binary-diving.
Microsoft killing VB and leaving all that code stranded to 32-bit processes in a 64-bit world.
Someone couldn't see the future and wrote the best file manager using tools that would be abandoned too soon.
Someone else for even discovering this discrepancy.


But it leaves me with three options...
1) Modify these "broken" shortcuts (and more in the future).
2) Leave them then curse when they don't work from XY, and eventually open them through other means.
3) Or finding a workaround - which sadly keeps hitting roadblocks & smartness in XY's opening/PFA code.


Disregarding all of that, I believe it to be bug that XY opens shortcuts with non-existing targets without running them through PFA first - as evidenced by the offline network shortcut.

[admin]

I'll check that tomorrow. Out of office for today....

[admin]

Next version should improve it.

[TheQwerty]

This doesn't seem much better in 14.80.0004.
While PFAs for lnk now work, it still doesn't work if the target is not found; as-is the case for removable drives, shares, and these crappy environment variable shortcuts.

I believe XY does this:

1. If item's target path does not exist - show error.
2. Else If item's path matches a PFA - do that.
3. Else Pass to Windows

Which means PFA is never checked for shortcut targets, so a shortcut pointing to a txt file always uses the system default when there's no match for lnk. Plus, as mentioned above, for not found targets the entire process is still aborted too early.

This would be better:

1. If item's true path matches a PFA - do that.
2. Else If item has a target path which matches a PFA - do that.
3. Else If item's target path does not exist - show error. (Is this really necessary?)
4. Else Pass to Windows

[admin]

You mean it should first check whether any PFA matches LNK files? And only resolve LNK if there is no match?

[TheQwerty]

You mean it should first check whether any PFA matches LNK files? And only resolve LNK if there is no match?

Way to test my memory...

I think I felt the flow should be...
Given 'C:\Shortcut.lnk' which has a target of 'C:\file.txt'...

1. If a PFA match for 'C:\Shortcut.lnk' is found - do that.
2. Else if a PFA match for 'C:\file.txt' is found - do that.
3. Else if 'C:\file.txt' does not exist - show error.
4. Else hand it off to Windows.

The reasoning was that currently XY seems to check if 'C:\file.txt' exists before all else and aborts the entire process when it doesn't, meaning it never bothered to check for a PFA definition for 'C:\Shortcut.lnk'.

EDIT: ...

[admin]

Tested it, and don't like it:

'C:\Shortcut.lnk' matches too many of my definitions (I have many catch-all defintions = "*"), so the shortcut target will never be reached. No good.

[TheQwerty]

Tested it, and don't like it:

'C:\Shortcut.lnk' matches too many of my definitions (I have many catch-all defintions = "*"), so the shortcut target will never be reached. No good.

Phooey... even if it was restricted to non-catch-alls on that first check?

[admin]

This is getting to complicated. PFA is a time proven machine. Let's leave it in peace for a while.

[TheQwerty]

The reasoning was that currently XY seems to check if 'C:\file.txt' exists before all else and aborts the entire process when it doesn't, meaning it never bothered to check for a PFA definition for 'C:\Shortcut.lnk'.

Can you at least move this existence check to after the PFA checking? Or add a tweak to skip it and let Windows inform me the file doesn't exist?

Part of what opened this worm-can is these stupid installers using %programfiles% but not installing to both bit specific Program Files directories.

Checking for the existence before the PFA means they just never work.
If the check was after the PFA then I can use PFA to course correct these.