ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Why is the default for the tar.longFile LONGFILE_ERROR?
Date Fri, 09 Feb 2001 05:00:34 GMT

> From: Sam Ruby []
> Those who have been following the theads on
> know that I am very
> concerned
> about version to version compatibiliy issues.

Yep. Me too.

> A longFile attribute will be introduced in 1.3.  Meanwhile this change
> makes it difficult to produce build.xml files which work on both 1.2 and
> 1.3.  Specifically, projects like xerces and xalan which didn't know that
> they were broken before are in fact broken now.

The reason I didn't make GNU the default mode was that I didn't want people
to silently be generating tar files which are not universally applicable. As
you know GNU tar files cannot be used on Solaris, for example. I wanted a
decision to go to GNU to be an explicit choice. I had envisaged the
possibility of being able to say longfile="sun" in the future but we would
need to know the Sun tar mechanism for handling long file names, which I
don't know at the moment.

I think the POSIX standard says you should warn when a path is > 100 chars
and then truncate. That isn't a great solution, though, IMHO.

> Looking into the implementation of the tar task, what I'd
> recommend is that
> the check for length of names be done within the tar task itself.  When a
> long name is encountered, the options are to skip, warn, or
> error; with the
> default being to warn (log) and proceed to encode using using GNU.

That shouldn't be a problem.

> I'm willing to do the work, and am even willing to do it only in the 1.4
> branch if the timing is not right for this type of change in 1.3.

I'd like to get this right for 1.3 so I would prefer if you make the changes
in the 1.3 branch. I would see a Beta 2 being produced after that and
possibly a merge into MAIN at that point to pick up the change for gump.

> Thoughts?


View raw message