Dereference .LNK file (in Windows only)

[Sergiy Radyakin]

Windows link file (shortcut file) associated with a Stata data file can be opened in Stata from the open dialog (db use). However an attempt to use the link file causes a problem, since Stata sees the binary content of the link file directly, not the associated data file.

How do I tell Stata to follow the link and use the associated data file in the use command to programmatically replicate the same action that I can do via a dialog?

In other words I am searching for implementation of dereference in:

local filedta=dereference("filelnk")
use `filedta'

Thank you, Sergiy Radyakin

PS: I am interested only in a programmatic solution, I am aware of the "open file location" menu item

[Joe Canner]

Sergiy,

This isn't what you were asking, but I suspect this is where you are heading...

In case you don't already have it, here is the file format for a .lnk file, which could be used to dereference a .lnk file.

Regards,
Joe

[Sergiy Radyakin]

Thank you Joe. There is an official description from Microsoft:
http://msdn.microsoft.com/en-us/library/dd871305.aspx
I was hoping for implementation.
S.R.

[Joe Canner]

Sergiy,

After perusing the .lnk file specifications for a while, I was able to come up with a program that could dereference a link file (attached). It worked for the one test case I tried it on, but it has not been exhaustively tested. I do know that this won't work if the file is on a network volume, although that would not be hard to add. You are welcome to modify to suit your needs.

If you are interested in turning this into a publicly available program, be my guest. If not, I may eventually do so after I am convinced that it works generally.

Regards,
Joe

[Sergiy Radyakin]

Dear Joe,
thank you for looking into this. The code you posted worked for one file I have, failed for another, and the third one turned out to be a problem for Stata itself (unicode in path). The error message was: may not seek past end of file r(651);

---

I don't recall seeing 100 constant for length of fields. Where is it coming from?

file read t %100s path1

The path can definitely be longer than 100. The file contains the length of its strings immediately before the strings.

---

In general I am not completely sure it is even possible to dereference the LNK file without access to registry. Or even more in general, I doubt that the LNK file contains all the necessary information to be able to recover the full effective path even following the specification accurately. For example the network administrator may enforce a policy to relocate the user's "Desktop" location. In that case the effective location will be conditional on the policy being effective at the moment. 32- and 64-bit systems can also view the LNK files differently, causing some confusion at dereferencing the "Program Files" special folder.

---

External tools like lp exist, and although I can't use it here, they demonstrate the complexity of the task of standalone parsing.

I was more inclined into delegating this job to Windows OS itself by invoking its API. Currently, plugins look like the only way to do it. Or avoid links, and force the user to provide the file directly, which is probably what I will have to revert to.

Thank you, Sergiy Radyakin.

[Joe Canner]

Sergiy,

100 was just a guess as to the longest pathname. I think Windows allows much longer pathnames. The field with the pathname is terminated with a NULL (00), so I suppose to be totally accurate, one should read a single character at a time until reaching the NULL. In practice, the NULL seems to keep Stata from reading more than what it should.

Yes, I don't doubt that there are a number of exceptions that would cause a simple-minded approach to fail. However, with appropriate caveats, it could be useful, although the whole point of using links is to make their use transparent to the user, so if you have to add an extra step to dereference the link, that kind of defeats the purpose. What would be really nice, is if Stata could make the use command accept .lnk files.

Good luck!

Regards,
Joe

[Sergiy Radyakin]

Joe, Microsoft writes that "...string MUST NOT be NULL-terminated". (Microsoft's capitalization in the original.)
See last sentence here: http://msdn.microsoft.com/en-us/library/dd871306.aspx
It also illustrates the fields lengths stored prepending the string content.

I agree 100% that use (and other file commands for that matter) should be supporting links as it opens a great flexibility resource. However implementing it by directly parsing the LNK file is quite tedious and this is platform-specific, so unlikely there is anything in Java to do it either (AFAIK even reading from the registry in a platform-neutral language like Java is a very non-trivial task).

Thanks for the good wishes. Have a great long weekend! Sergiy.

[Joe Canner]

Hmmm...I'm not sure what that is referring to, but I don't think it is relevant to the particular field that you need to get the target file from. On page 22 of the Microsoft PDF from the link you posted earlier it says:

LocalBasePath(variable): An optional,NULL–terminated string,defined by the system default code page, which is used to construct the full path to the link item or link target by appending the string in the CommonPathSuffix field.
...
CommonPathSuffix (variable): A NULL–terminated string, defined by the system default code page, which is used to construct the full path to the link item or link target by being appended to the string in the LocalBasePath field.

If you look at the example in Section 3, you will see that the string with the LocalBasePath is NULL-terminated.

The "...string MUST NOT be NULL-terminated...." sentence refers to a particular data structure in which the string is preceded by a field indicating the length of the string; hence no NULL termination needed. I think this is an optional data structure that might have something to do with finding the file if the link is broken.

Anyway, have a great holiday!

[Phil Schumm]

Windows link file (shortcut file) associated with a Stata data file can be opened in Stata from the open dialog (db use). However an attempt to use the link file causes a problem, since Stata sees the binary content of the link file directly, not the associated data file.

I'm just curious: Why wouldn't you use a symbolic link instead?