If you’re geek enough, the documentation for the shortcut file format is here:
Note that these LNK files can point to a lot of things other than just a plain old disk file.
The exact semantics of how a broken link is resolved are not documented here, and my half-assed search didn’t find a good reference to those semantics. Which may be deliberately “undocumented” as MSFT puts it, meaning that they aren’t going to set in stone a behavior guarantee for all time; we just have to accept that “it just works” for somewhat variable definitions of “works”.
I had the same motivation when reorganizing my music library last month. Unfortunately I did most of the work on an old laptop, with the idea that I’d eventually remove the hard drive and put it into an external enclosure, then plug in the external drive and copy the files to a new machine. When time passed and the old laptop was still proving too useful to decommission for hard drive extraction, I opened an FTP session over the local network and started backing up the music library that way. Guess what the FTP protocol does with symlinks, even if they point to a relative path? It resolves them! (At least that’s how the protocol was implemented by my client; there might be other FTP clients that do something more intelligent when the saving-space motivation is clearly the user’s intent.) All the space I intended to save (by having symlinks instead of multiple copies of the same file) was promptly occupied on the hard drive of the new machine.
One issue with hardlinks (or symlinks) is that you can’t set a working directory. Not a huge deal for most file formats, but they don’t work well with executables.
[quote=“biqu, post:22, topic:931165”]
… I opened an FTP session over the local network and started backing up the music library that way. Guess what the FTP protocol does with symlinks, even if they point to a relative path? It resolves them! … All the space I intended to save (by having symlinks instead of multiple copies of the same file) was promptly occupied on the hard drive of the new machine.[/quote]
Maybe FTP wasn’t the best tool for this kind of LAN backup. I’ve since found a different solution that uses netcat and tar, thereby achieving the low overhead that I was aiming for by eschewing the checksum or encryption algorithms of rsync or ssh. Perhaps eschewing the checksum is an invitation to data corruption, but for a non-critical folder like a music library, I can live with the risk.
On the receiving machine: nc -l -p 1234 | tar xvf -
On the sending machine: tar cvf - * | nc -N receiver 1234
Apparently the original FTP specification had no provision for creating symlinks. Some server/client pairs will allow this extension of the protocol if the user has shell access on the target machine. For example, the documentation for lftp mentions a “mirror mode” that would appear to work like the “archive mode” of rsync. But if the server disallows symlink creation entirely, regarding it as a security vulnerability, then lftp obviously won’t be able to achieve the desired effect. One such server is Pure-FTPd, whose FAQ states:
Please note that the FTP server will never let people create new symbolic links. Symbolic links have to be already there to be followed. Or if your
users can create symbolic links through Perl or PHP scripts, your hosting
platform is really badly configured.
