Hard Links

[Scott Palmer]

On Fri, May 13, 2011 at 5:16 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> Scott Palmer wrote:
>
>> :
>> I suppose I can file a RFE, as it seems a bit imbalanced to support
>> hardlink creation in a cross-platform way, but only provide a way to get the
>> link count on unix.  After all, it isn't feasible to create a hardlink
>> everywhere either… but as I mention above, the decision was made to support
>> them in a cross-platform way by including createLink in the API. It seems
>> the support is only missing this tiny bit to be "complete".
>>
>>
> The method is marked as "optional operation" (same thing for the methods
> that operation on symbolic links too) and throws UOE if not supported. The
> only reason that createLink is there is to allow for file synchronization
> tools, it's unlikely to be used much beyond that.
>

The use case that I came across just 2 days ago was for running Mercurial on
Jython.  Mercurial makes use of hard links to make fast and space efficient
local clones, but it needs to know the link count so it can break the hard
link if it needs to make a change to the repository for only one of those
clones.  One of the issues was that Java had no APIs to deal with hard links
- partially solved in Java 7.  It can be worked around of course.   My view
is that if there is a feature common to multiple platforms it would be best
solved with a cross-platform API though.

I can see uses in things that mimic Apples "Time Machine" backup tool as
well - basically the file synchronization tools that you mention.


> As I said, the support for attributes is very extensible so if there is a
> good case to add it to the API they it could easily be added as part of an
> extended view. Not for jdk7 of course as only critical things are allowed in
> now. It could also be supported on a per provider or platform specific basis
> if needed too (as I say, it just never come up, and has not been in the API
> for two years).
>

I think that an extended view for Windows would make sense then.  It could
be an open source project at first and  perhaps it could be rolled in to a
future version if it proves useful.

Thanks,

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110513/f317179a/attachment.html