Re: Creating a Windows Shortcut

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 07/09/2019
12:22:49 PM:

----- Message from John Yeung <gallium.arsenide@xxxxxxxxx> on Mon, 8
Jul 2019 18:55:05 -0400 -----

To:

RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>

Subject:

Re: Creating a Windows Shortcut

On Mon, Jul 8, 2019 at 5:45 PM Justin Taylor <JUSTIN@xxxxxxxxxxxxx>

wrote:

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.

That's... hard to believe. If it's true, then sure, that's not a great
option. But... well... nobody else does hard links that way, and I get
that IBM likes to be different, but this would be different in just
about the stupidest way imaginable.

My own experience is not suggestive of hard links existing as
space-consuming mirrors, even on IBM i. I made some hard links (using
the `ln` command from Qshell) to stream files that are close to a
gigabyte in size, and it happens almost instantaneously. This is on a
pretty small, entry-level system.

Also note that he said symlinks are all just 1 KB. So, whatever he is
using to look at the file size is telling him the file size of the
*link file*. But this same method of looking at file sizes *should*
tell him that a hard link is the same size as the original. It
actually should not be possible to distinguish a hard link from an
"original", which by definition is itself a hard link.

John Y.

John,

Your thinking is correct a hard link does *not* take any additional space
for the actual data to which it points--this is generally called an i-node
(there is a small amount of storage--read negligible--used for the hard
link itself). What you see is the actual storage "underneath the covers."
A simplified way to look at a hard link would be to think of it as a
directory entry pointing to actual file storage. You can have multiple
hard links to the same file. You can do anything to the file (delete,
update, move, etc.) and the hard link stays fine as it is just a directory
entry pointing to the file. When the last hard link to the file is deleted
(i.e., UNLINKed), the actual file (i.e., i-node) is deleted.
(Incidentally, the authority to all hard links is the same--i.e., it's
only stored on the i-node.)

A symbolic link is more like a shortcut. If the actual data file is moved,
the symbolic link is broken. If a new file with the same name is created
in the original location, the symbolic link points to the new file.

Michael Quigley
Computer Services
The Way International