This is a request to add the ability to detect/create/delete symbolic links in the java.io.File class.

For example, one of our licensees would like to do:

How does one create symbolic link in java? Also how does one detect if a 
directory name is a symbolic link and get the link destination? 

I went through java.io.File class which does not seem to have any methods for 
these purposes.

In our installation program we have to do something like the following through a 
java program.

Assume that /var/opt/ customer /MSS01 is a link to /opt/ customer /MSS0101.

	Check to see if /var/opt/ customer /MSS01 is a symbolic link
	If it is get the directory name it points to 
	Remove /var/opt/ customer /MSS01 
	Create /var/opt/ customer /MSS01 as a link to another directory 
/opt/ customer /MSS0102

===============================================
Another report from   xxxxx@xxxxx  :

It would be nice if Java had a concept of symbolic
link (java.io.symlink?). I believe symbolic links
are common to most major OS (aliases in Windows/Mac)
and this could be a no-op on other platforms.

It should probably be a subclass of java.io.File
and have methods to find what it is linked to.

  xxxxx@xxxxx   1997-11-20
==================================================================
Posted Date : 2006-04-11 20:21:25.0

N/A

This issue will be addressed in the New I/O work.
--   xxxxx@xxxxx   2000/3/9
The open RFE for JSR-203 to address this issue is 6350340.
Posted Date : 2006-04-11 20:21:26.0

Requires native code or 'exec'-ing native programs

Links, symbolic and hard, should be supported 
in java as specified by POSIX.  Unix platforms 
always support links, and WinNT apparently does 
so too: <http://www.mvps.org/win32/ntfs/lnw.html>.

That should be supported, I want to do something
like the Unix "find" command, and recursing into
links can result in an infinite loop. I think that
a 'File.isLink()' would be sufficient.

The File abstraction in Java is really weak. It is based on the assumption that
the location and name of a file is the file's identity, rather than an attribue
of the file. Many operating systems (eg Mac and I assume Windows) have moved
well beyond that method to specify the identity of a file. What we need is a
class to use instead of java.io.File that _is_ a symbolic link.

Here's hoping it comes about soon.  I abandoned my own
version of find with java.io.File in favor of 'exec'ing a
Unix version of "find".

Any suggestionions on how to do this in NT?  I have no idea
whether NT supports or uses links, my code seems to work on
it but it's going to target a variety of users.

I find it surprising that Sun would not have fixed this much earlier given that Solaris must exhibit this problem.  One 
cannot recursively visit the files and disks because there is no way to tell when you are in a loop due to a symbolic 
link.  Furthermore, the so called "canonical" path name is not canonical (at least on the Linux 
implementation of Java).. it just gets longer and longer as you go around the loop!  Please fix this ASAP and in 
older versions of Java as well!

The work around is as follows. It works for me on AIX.

Assume, there are two files (/opt/a.txt, /opt/b.txt). Here "b.txt" is a symbolic link to "a.txt".
File system listing shows (b.txt -> a.txt).

File f = new File("b.txt");
System.out.println("Canonical : "+f.getCanonicalPath());
System.out.println("Absolute : "+f.getAbsolutePath()); 

Output :

Canonical : a.txt
Absolute : b.txt

So, when the absolute path is not equal to canonical path, it is a symbolic link. Absolute path is the link 
itself and the canonical path is the original file.

If there is a symbolic link (c.txt -> b.txt -> a.txt), then for 'c.txt', absolute path is 'c.txt' and canonical 
path is 'a.txt'. So, you can use JNI and issue a "readLink" system call to get 'b.txt' and so on till you reach 
'a.txt', which is the end of the link chain.

I have tried the approach of comparing a file's absolute path to it's canonical path... but I don't believe it is reliable.

For example, imaging you have /opt/dirA as a symbolic link to /opt/dirB... and that you have a file called 'test.txt' inside this directory.... comparing 'test.txt's absolute path to it's canonical path would lead you to think that test.txt is itself a symbolic file... whereas it isn't...

Absolute Path: /opt/dirA/test.txt
Canonical Path: /opt/dirB/test.txt

Please can we have a proper fix for this issue.

NTFS reparse point is kind of symbol link (for absolute path only) and it's unknown by all but a few special tools, so if you create it from your program, the users will likely to be confused...

I heard vista is going to have a real, unix-like symbol link support, anyone can confirm this?