blog: miniscrap and network items

[nikos]

here's the comment area for today's blog post found at
http://zabkat.com/blog/network-miniscrap.htm

[Kilmatead]

The miniscrap pane doesn't like it when you put in it inaccessible items. It will remove such items.

Jolly good of you to provide a log of things it tossed away (never to be seen again) though. Anthropomorphic allusions aside, why not just tell people the real reason why this happens, and why they might as well just use shortcuts or (better yet) reparse-points for everything?

cida is the native tongue for shell item identification. Not all items have text paths (think virtual folders), especially for older windows, therefore the cida solution is the correct choice

Native tongues not lookin' so sweet now, are they? Everything's a workaround with you, isn't it?



On a somewhat related note, why doesn't the Shortcut To [S] column display anything for relative-path symlink targets? Works fine for absolute. Can't be that tough to resolve them...

[nikos]

how did you create a relative path target? does it resolve when you press CTRL+L?

[Kilmatead]

No, they don't resolve with <Ctrl+L>, surprisingly - you really should fix that. Relative-paths are a legitimate content directive for REPARSE_DATA_BUFFER structures (SYMLINK_FLAG_RELATIVE = 0x00000001) - that LinkShellExtension toy that RightPaddock is always raving on about creates them by default for objects local to the current drive. This can be changed in the settings, but hey, they are what they are.

My little toy handles them correctly, he says smugly.

[nikos]

and do these little monsters you created work at all, pray?

[Kilmatead]

Of course they do - they resolve just fine when you click on them, or sprinkle them over pasta during the normal course of events. They're just standard reparse-point targets, merely with their buffer-target-data relative to the original link-container itself. Kinda handy, they are, too.

As the LSE creates them by default, I would imagine more than a few users have them all over their drives, but never realised that the Shortcut column is supposed to apply to all reparse links as well. And that <Ctrl+L> thing is a definite boo-boo.

[Kilmatead]

You can create one yourself to test (and dissect, if necessary) just by using the API's CreateSymbolicLinkW call - use "C:\Test" as the lpSymlinkFileName and ".\Program Files" as the lpTargetFileName (and dwflag SYMBOLIC_LINK_FLAG_DIRECTORY, obviously). Works fine.

(When reading the resulting link, PathBuffer will contain [raw] ".\Program Files.\Program Files" as expected, and Flags being SYMLINK_FLAG_RELATIVE [Flags is 0 if an absolute path is used - it has no other values, as far as I know].)

[nikos]

ok i will sort it out

[RightPaddock]

ok i will sort it out

Could that include getting Alt/Enter on a Folder Symlink to do the same as Alt/Enter on a Junction - ie open the target in the other pane.

On 1.8.1.4, 2.4.0.1, and 2.5.0.2 Alt/Enter on a Folder Symlink pops the Properties Sheet container of the Folder Symlink

This issue has been around since at least 2008 (soon after the Vista launch), and I recall a thread started by Thracx a couple of years ago it which it was also raised Ψ²

BTW, if you wanted another reference for symlink creation software, Lopesoft's FileMenuTools does them. It doesn't have all the bells and whistles that LSE has, nor is it as convenient to use as LSE in a two pane file manager such as X2, but it's probably 'good enough' for most folks. You get other goodies too - like a folder size tool that takes hardlinks into account - ie no double counting.

RP

[Kilmatead]

On 1.8.1.4, 2.4.0.1, and 2.5.0.2 Alt/Enter on a Folder Symlink pops the Properties Sheet container of the Folder Symlink

Umm - no it doesn't. Both absolute and relative symlinks open in the opposite pane when using <Alt+Enter>, just like Junctions. I get no properties sheet opening (except for file-objects, but that's to be expected - folders work fine).

I tested both the x64 Pro and Ultimate versions (back to 2.2.0.0 which is the oldest I have. They work as expected on Win7. (And yes, the links were created with LSE.)

(FileMenuTools only creates absolute symlinks, not relative. And it's a really awful implementation - LSE is more convenient, though it would be better if Drop As wasn't relegated to an annoying submenu in x2... I just wish that x2's ability to replicate the original timestamps of symlink files upon creation was carried over to folders too - but I suppose that's why I had to do it myself...)

[RightPaddock]

On 1.8.1.4, 2.4.0.1, and 2.5.0.2 Alt/Enter on a Folder Symlink pops the Properties Sheet container of the Folder Symlink

Umm - no it doesn't. Both absolute and relative symlinks open in the opposite pane when using <Alt+Enter>, just like Junctions. I get no properties sheet opening (except for file-objects, but that's to be expected - folders work fine).

Not here mate - even if I use X2 to create the folder symlink.

I didn't know Alt/Enter popped properties on files, I use menu/↑/enter or F12.

I just did a reboot into Safe Mode and I get the same thing. So its not the usual suspects like Shelltoys, FMT, etc. I can't think of anything else that would be interfering with X2 at this level.

Maybe I should reinstall a totally fresh copy of X2. This one dates back to W7 beta days. But I should probably do that after I do a bare bones Windows 7 install, it's over 5 years old. Or maybe I will continue living without it and wait for Win9 and X2 3.0.

RP