Bug 35776 - amend FileUtils to properly handle cygwin symbolic links
Summary: amend FileUtils to properly handle cygwin symbolic links
Status: REOPENED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0
Hardware: Other other
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-18 13:35 UTC by Ralf Hauser
Modified: 2008-02-22 12:18 UTC (History)
3 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2005-07-18 13:35:36 UTC
org.apache.tools.ant.util.FileUtils is a great tool to create platform
independent paths:

        FileUtils fu = FileUtils.getFileUtils();
        return new Location(Locator.fromURI(fu.toURI(fileName)))
                .getFileName();

Unfortunately, when a path is using cygwin symlinks, it still won't work.

There is a resolveFile() that already does more than just new File(file,
filename), but unfortunately, it wouldn't notice if a file doesn't exist (due to
being a cygwin symbolic link).

Once this exists, I guess this very useful tool "FileUtils" might find many more
takers and thus could move to jakarta-commons?
Comment 1 Matt Benson 2005-07-21 17:19:28 UTC
(In reply to comment #0)
> Unfortunately, when a path is using cygwin symlinks, it still won't work.
> There is a resolveFile() that already does more than just new File(file,
> filename), but unfortunately, it wouldn't notice if a file doesn't exist (due 
to
> being a cygwin symbolic link).

Cygwin symbolic links are a pecularity unto themselves. Further, I don't know 
that there is any guarantee that their implementation has never changed, and 
will never change.  This means that any code we wrote, making assumptions about 
the implementation of cygwin symlinks might not work against older or future 
versions of cygwin.  Beyond that, cygwin not being a true OS it would be a 
judgement call whether supporting its symlinks would be proper.  More likely 
the "right" way to get this would be to build cygwin awareness into a JVM, 
since it is at this level that, e.g. Unix symlinks are handled.

> Once this exists, I guess this very useful tool "FileUtils" might find many 
more
> takers and thus could move to jakarta-commons?

IIRC there is at least one jakarta-commons project [io] with a FileUtils class.
Comment 2 Ralf Hauser 2005-07-21 18:04:06 UTC
thx to Matt for the pointer to the existing commons-io FileUtils (see Bug 35818).

Agreed, having symlinks handled by the JVM might be the best solution. But since
we all stumble daily over those and JVMs haven't delivered on this so far, why
not aiming for the second best and giving it a (temporary) home in the jakarta
family of projects? (instead of everybody making his own
half-hearted-quick-fixes all the time)

Also, "This means that any code we wrote ... might not work against older or
future versions of ..." - isn't that true for almost any interface/third-party
component one programs against/with?
Comment 3 Matt Benson 2005-07-21 20:19:17 UTC
(In reply to comment #2)
> thx to Matt for the pointer to the existing commons-io FileUtils (see Bug 
35818).
> Agreed, having symlinks handled by the JVM might be the best solution. But 
since
> we all stumble daily over those and JVMs haven't delivered on this so far, why
> not aiming for the second best and giving it a (temporary) home in the jakarta
> family of projects? (instead of everybody making his own
> half-hearted-quick-fixes all the time)

One idea: extend oata.types.FileSet -> CygwinFileSet (e.g.), which returns an 
extended oata.DirectoryScanner that knows how to resolve cygwin symlinks.  The 
result is a drop-in replacement for fileset (using typedef though I know Steve 
L. will complain ;) and any compatibility risks are undertaken voluntarily by 
the user.

> Also, "This means that any code we wrote ... might not work against older or
> future versions of ..." - isn't that true for almost any interface/third-party
> component one programs against/with?

Indeed; however most third-party components do not masquerade as the filesystem.

By the way, don't get me wrong here.  I have been a loyal cygwin user for quite 
some years now.
Comment 4 Igor Peshansky 2006-08-28 04:48:22 UTC
(In reply to comment #3)
> > Agreed, having symlinks handled by the JVM might be the best solution.
> 
> One idea: extend oata.types.FileSet -> CygwinFileSet (e.g.), which returns an 
> extended oata.DirectoryScanner that knows how to resolve cygwin symlinks.  The 
> result is a drop-in replacement for fileset (using typedef though I know Steve 
> L. will complain ;) and any compatibility risks are undertaken voluntarily by 
> the user.
> 
> > Also, "This means that any code we wrote ... might not work against older or
> > future versions of ..." - isn't that true for almost any
> > interface/third-party component one programs against/with?
> 
> Indeed; however most third-party components do not masquerade as the
> filesystem.
> 
> By the way, don't get me wrong here.  I have been a loyal cygwin user for
> quite some years now.

FWIW, one solution that would not involve modifying the JVM is a native method
shipped with a DLL that's linked with Cygwin.  That way you can guarantee that
any path conversion will invoke the genuine Cygwin functionality, so
compatibility will not be an issue.
Comment 5 Matt Benson 2006-08-28 14:28:10 UTC
(In reply to comment #4)

> FWIW, one solution that would not involve modifying the JVM is a native method
> shipped with a DLL that's linked with Cygwin.  That way you can guarantee that
> any path conversion will invoke the genuine Cygwin functionality, so
> compatibility will not be an issue.

This sounds like an interesting project, but I personally don't have time to
attempt it given my laughable C-Fu and complete lack of knowledge of the cygwin
APIs.  I'm sure that when a patch implementing this solution is submitted it
will be given due consideration.
Comment 6 Antoine Levy-Lambert 2006-08-28 16:57:10 UTC
I would not personally support adding cygwin support in ant at this level.
Maybe the people who are interested by specific cygwin functionality should
start their own Java project ?