RE: Creating a Windows Shortcut

A symlink in a NetServer share shows the actual file size to the client. I assume he means that making a hard link actually takes up the file size on DASD.



-----Original Message-----
From: John Yeung [mailto:gallium.arsenide@xxxxxxxxx]
Sent: Monday, July 08, 2019 4:41 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Creating a Windows Shortcut

1. It does need to be a Windows shortcut. The idea is simple: we're saving TIFF images to the IFS for a specific period of time, after which we're moving them to an archive directory. The directory to which we are sending them has a path structure such as //server/year/month/terminal/application/image.tiff. This specific format has meaning to us and we'll be able to find this image again years later. However, I want to include a shortcut to this image (in its archive location) in an alternate directory path structure such as //server/document_service_number/image.lnk. The document_service_number is a value that is known to my RPGLE program at runtime and this alternate directory path gives us an alternate method of looking up these archived images.

This doesn't explain why it needs to be a Windows shortcut. It doesn't even fully explain why you have to have a file system link at all. For example, why can't the RPG program use the true directory? Or, why can't you maintain your own table which maps true paths to document numbers and/or vice versa?

2. [...] If I create a hard link, and give the file the same name (different location) and extension, then the file is created and can be opened with a double click. The downside to a hard link is the file size -- it's the same as the original file to which it points.

This is one reason I asked who the Windows shortcuts are *for*. If they are for normal users, what does it matter what the file size shows up as? If anything, wouldn't it be more useful to see the true storage size of the original file, and any other information that would be reflective of the true file, rather than the size of a shortcut file? Maybe it's worth mentioning that a hard link isn't a copy, it's a link. From a pure resource usage standpoint, it's probably even more efficient than a symlink, and definitely more efficient than a Windows shortcut.

If I create a symlink with the same file and extension, then the file
is created and can be opened with a double click AND the file size is 1KB (regardless of the size of the original -- I've tested with an original that's 498KB). The downside to using the QSHELL 'ln' command is that from the Windows side, the file is not a 'shortcut'. A minor issue, agreed, but not exactly what I was hoping for.

So, you've now said that both kinds of POSIX-style links let you double-click to open. What's left that the Windows shortcut gives you?
I have a feeling shortcuts mainly satisfy some combination of user comfort level and your own comfort level. This is what I mean by ruling out *technical* issues.

From what you've described so far, hard links actually seem perfect.

John Y.