× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.