how to detect a hard link in Java?

[jojo]

I have an application need to detect the hard links within the unix
file systems. how to detect it and how to get the target path of this
link points to in Java?
thanks a lot

 

[Andrew Thompson]

I have an application need to detect the hard links ...

What's a 'soft link'?

 

[Wibble]

I have an application need to detect the hard links within the unix
file systems. how to detect it and how to get the target path of this
link points to in Java?
thanks a lot

You can either Runtime.exec("/bin/ls -il "+filename) and parse the
result, or grab a package like

http://www.bmsi.com/java/posix/package.html

which includes Posix.stat() to get the inode and the number of links
for a file or directory.

Files with more than one link are hard links. What it points to is
an inode. You pretty much have to search the file system for another
hard link with the same inode number.

 

[Monique Y. Mudama]

What's a 'soft link'?

Serious question, or are you just pointing out that this is
OS-dependent?

On a unix system the difference is between 'ln -s' vs 'ln' ... off the
top of my head ...

Hrm. It's hard to explain off the top of my head, even though I know
the difference at a gut level.

If you create hard links to a filename, each hard link is just as
valid as the original filename. It's just as proper to say that
hardlink1 "is" the file as it is to say that filename "is" the file.
When all hard links are removed, the file is deleted. A soft link, on
the other hand, is a pointer to a filename ... in fact, a soft link
may even be sensitive to relative path location, and will break if you
move the original file.

Hrm. Clear as mud. It's clear in my head =/

 

[Andrew Thompson]

Serious question,
Yep.

..or are you just pointing out that this is
OS-dependent?

Unfortunately I trimmed the part indicating OS
specific, but I understood that. No, I suppose if
I had any point, it would have been 'when dealing
with OS specific stuff, give a few wrods description
of what you mean', beyond 'like the help wizard in Word'..

If you create hard links to a filename, each hard link is just as
valid as the original filename. It's just as proper to say that
hardlink1 "is" the file as it is to say that filename "is" the file.
When all hard links are removed, the file is deleted. A soft link, on
the other hand, is a pointer to a filename ... in fact, a soft link
may even be sensitive to relative path location, and will break if you
move the original file.

Hrm. Clear as mud. It's clear in my head =/

OK. (chuckles) It least it clarifies that 'getCanonicalPath'
is not the answer to this one..

 

[Roedy Green]

I have heard the Linux term "symbolic link".

See http://mindprod.com/jgloss/linux.html

Is a symbolic link soft or hard?

 

[Jussi Piitulainen]

I have heard the Linux term "symbolic link".

See http://mindprod.com/jgloss/linux.html

Is a symbolic link soft or hard?

A man page for ln(1) says this of an option:

-s, --symbolic
make symbolic links instead of hard links

So a symbolic link is at least not hard. I think symbolic links may
also be called soft, sometimes.

As to the original question of somehow resolving a hard link, I don't
see how that can be done at all until some further criteria are
stated: the hard links to the same file are all equal, I think. We can
do things like the following.

touch orig (creates orig)
ln orig foo (aliases orig as foo)
ln orig bar (aliases orig as bar)
rm orig (removes the name orig; file remains as foo and bar)

Now there is a file that is known by the names "foo" and "bar", and
neither of them is its original name. Which should be the canonical
name? Maybe "bar" because it is alphabetically earlier. The aliases
might be in different directories, and then a shorter path might be
more canonical.

 

[Gordon Beaton]

I have an application need to detect the hard links within the unix
file systems. how to detect it and how to get the target path of this
link points to in Java?

It isn't possible (java or not).

A "hard link" is simply a directory entry that refers to an inode, in
common terms a filename. Files in unix can have multiple names
(without using symbolic or soft links), and none of them has any
precedence over the others.

In java terms, this is equivalent to holding several references to a
given object. All of them are equivalent.

/gordon

 

[Gordon Beaton]

What's a 'soft link'?

A file containing the name of another file. Treated specially by the
OS, such that most operations on the link are transparently redirected
to the target file instead.

/gordon

 

[Chris Uppal]

So a symbolic link is at least not hard. I think symbolic links may
also be called soft, sometimes.

Yes, "symbolic link" (sometimes shortened to "symlink") and "soft link" mean
the same thing. "Hard link" is really something a misnomer since there is no
"link" involved at all, at least no link between the two names, it's just that
the same data on disk can have more than one name in the file system.

(Or indeed no name at all -- which used to be a favourite way of creating
temporary files to hold ephemeral data, I don't know if it still is.)

-- chris

 

[Bent C Dalager]

Now there is a file that is known by the names "foo" and "bar", and
neither of them is its original name. Which should be the canonical
name? Maybe "bar" because it is alphabetically earlier. The aliases
might be in different directories, and then a shorter path might be
more canonical.

Of course, if the shorter path is /tmp/foo, then perhaps the other one
(whatever it is) should be considered canonical

Cheers
Bent D

 

[Hemal Pandya]

Now there is a file that is known by the names "foo" and "bar", and
neither of them is its original name. Which should be the canonical
name? Maybe "bar" because it is alphabetically earlier. The aliases
might be in different directories, and then a shorter path might be
more canonical.

Unix does not have a concept of a canonical filename. As a matter of
fact the file and its name are two separate things.

Java does. The javadoc for getCanonicalPath says its definition is
system dependent. But my experience on Linux and the hints is javadoc
suggest it does not have anything to do with the links to the file.

 

[Monique Y. Mudama]

OK. (chuckles) It least it clarifies that 'getCanonicalPath' is not
the answer to this one..

Well, that's a good point. With all of my rambling above, it didn't
occur to me that of course, getCanonicalPath()'s behavior on a system
allowing hard links might be ... unexpected.

 

[Virgil Green]

Serious question, or are you just pointing out that this is
OS-dependent?

On a unix system the difference is between 'ln -s' vs 'ln' ... off the
top of my head ...

Hrm. It's hard to explain off the top of my head, even though I know
the difference at a gut level.

If you create hard links to a filename, each hard link is just as
valid as the original filename. It's just as proper to say that
hardlink1 "is" the file as it is to say that filename "is" the file.
When all hard links are removed, the file is deleted. A soft link, on
the other hand, is a pointer to a filename ... in fact, a soft link
may even be sensitive to relative path location, and will break if you
move the original file.

Hrm. Clear as mud. It's clear in my head =/

Soft links (or Symbolic links) can survive the deletion of the target file.
IIRC, hard links are directory entries, but soft links are actually
directory entry/file pairs with the file containing the name of the path to
the target file. It is possible to have dead soft links.

That's if IIRC. I don't use these much.

 

[Joan]

I have an application need to detect the hard links within the
unix
file systems. how to detect it and how to get the target path
of this
link points to in Java?
thanks a lot

Suppose you have MS Windows that does a "Map Network Drive"
to access a drive on a unix box in Detroit, and further that
there
is a "Hard Link" on the Detroit box -- does it count? If so, I'd
use the
telephone.

 

[Jussi Piitulainen]

Of course, if the shorter path is /tmp/foo, then perhaps the other
one (whatever it is) should be considered canonical

Oops. Now the problem is fast becoming AI-complete.

But I thought of another technical snag, too. A program might not have
permission to access an alias that should be otherwise canonical, by
whatever criteria. (This is, of course, purely academic, given that
the search for the aliases would be prohibitively expensive anyway.)

 

[blmblm]

Well, that's a good point. With all of my rambling above, it didn't
occur to me that of course, getCanonicalPath()'s behavior on a system
allowing hard links might be ... unexpected.

Unexpected? It might depend on how you interpret "path", no?
because it seems to me that getCanonicalPath() only claims to provide
a unique representation of a path, not a file. So if there's more
than one path representing a file (as will be the case if you have
two "hard links" that reference the same file), there would be more
than one "canonical path" for the file.

Or were you thinking of something else?

(And I (think I) know just what you mean by it being clear in your
head, but difficult to explain. I'm not sure I could do better
without mentioning inodes, which seems like a lot of detail to drag
in to explain the basic idea.)

 

[John C. Bollinger]

Unix does not have a concept of a canonical filename. As a matter of
fact the file and its name are two separate things.

Maybe and yes, but your second statement is irrelevant. On Unix, given
a filename and, if necessary, a context path, it is possible to
construct a canonical filename. One algorithm might be to resolve the
filename against the context path to create an equivalent absolute
pathname, and then to recursively resolve all symbolic links. In fact,
I believe this is what Sun's java.io.File implementation does on Linux
and Solaris. It is important to understand here that java.io.File does
*not* represent files in the usual sense -- rather, it represents
pathnames in an hierarchical filesystem. (The docs are actually quite
clear on that.) The underlying file, if any, is quite beside the point,
so the fact that two different canonical pathnames may refer to the same
underlying file is therefore in no way inconsistent (though it might
produce surprising behavior, which is one reason why hard links are evil).

 

[Raymond DeCampo]

Maybe and yes, but your second statement is irrelevant. On Unix, given
a filename and, if necessary, a context path, it is possible to
construct a canonical filename. One algorithm might be to resolve the
filename against the context path to create an equivalent absolute
pathname, and then to recursively resolve all symbolic links. In fact,
I believe this is what Sun's java.io.File implementation does on Linux
and Solaris. It is important to understand here that java.io.File does
*not* represent files in the usual sense -- rather, it represents
pathnames in an hierarchical filesystem. (The docs are actually quite
clear on that.) The underlying file, if any, is quite beside the point,

[Separated for emphasis]

so the fact that two different canonical pathnames may refer to the same
underlying file is therefore in no way inconsistent (though it might
produce surprising behavior, which is one reason why hard links are evil).

It is inconsistent with the definition of the word canonical. A
canonical form should be unique.

Ray

 

[John C. Bollinger]

John C. Bollinger wrote:

It is inconsistent with the definition of the word canonical. A
canonical form should be unique.

I'll make that stronger: a canonical form *must* be unique. The
canonicalization algorithm used by a Java implementation meets this
criterion or it is broken. The issue, though, is the definition of
"unique" in the problem domain. On UNIXen, and perhaps other systems,
whether or not two pathnames refer to the same inode is not a relevant
criterion for this decision, as File objects have nothing whatsoever to
do with inodes, and have only an arm's-length relationship with any file
referred to by the *path* they represent -- if, indeed, there even is
such a file. Canonicalization is relative to the node in a hierarchical
filesystem tree represented by a File, and how or whether that
corresponds to any actual data is not relevant.

Do read the class-level docs of java.io.File if you haven't before. The
class is somewhat misnamed, IMO, and it's important to this discussion
to have a firm grasp of what it actually represents. (As I wrote in a
previous post, that's a path, not the actual file referred to by a path.)