Reply viewing options

The createLink and createSymbolicLink methods create hard and symbolic links. These are in the file system. Are you assume they these methods create Windows short cuts by any chance? The file system doesn't know anything about these.

I was tricked, cause if you create a symbolic link pointing to a file and name it with the Windows shortcut ending ".lnk" and take a look at the properties of the resulting file, you can see the target of this symbolic link in the windows properties dialog and it behaves like a shortcut file, but you can't change the other attributes of it.

As soon as you rename it to the target "file ending" the link works perfect.

I need to be able to read links created by Windows users and thought the nio classes would eliminate my usage of the deprecated ShellFolder class, doing like this:

But I guess I'm stuck with this awt class for a while, it would be really nice if you incorporated that functionality in the nio package. Cause windows users still creates .lnk shortcut files (even in Server 2008, Vista and Windows 7 - which supports symbolic links).

The file system API has a provider interface and it would be nice for someone to develop a desktop provider that knows about short cuts, virtual directories, and other shell concepts that the file system doesn't know anything about. The default provider doesn't know about these things of course because they aren't known to the file system.

As regards the code fragment you post, you should not use sun.* classes directly.