git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [2/2] ant git commit: Bz 22370: followlinks attribute


On 2018-06-06, Gintautas Grigelionis wrote:

> 2018-06-06 14:31 GMT+02:00 Stefan Bodewig <bodewig@xxxxxxxxxx>:

>> I guess here our API breaks down as we only ever deal with files or
>> directories (outside of the symlink task).

> FileSet documentation should be more explicit about the matter, in
> particular explaining what "followsymlinks" really means.

You are right. In a Java world where you couldn't really do anything
with symlinks it has probably been clear implicitly.

>> Would the symlink be included in DirectoryScanner's "included files" or
>> "included directories"? What will <copy> do to a symlink that is
>> included but not followed.

> "Files or directories" dichotomy might be a straitjacket, but symlinks can
> be fitted into it depending on what their target is.

DirectoryScanner's interface provides you with files and directories and
as it stands these File objects may actually by symlinks and the
implicit expectation is that whoever uses them follows the links and in
the end works on the target.

We could add new array of symlinks that are not supposed to be followed
but most tasks would simply ignore them (all tasks that we don't change
ourselves).

> Dangling symlinks should go into notFollowedSymlinks.  Regarding
> <copy>, included but not followed symlink must be left as is (eg
> directories are not filtered either).

Probably. There will not be a interpretation that will work for all
tasks, it will be on a task by task basis. As we can only control the
tasks that are inside of Ant's codebase, this means we must not change
the interpretation of the files and directories returned by
DirectoryScanner at all.

> I wonder if we can have an interim solution when selectors could use
> proper followsymlinks semantics, but behaviour of DirectoryScanner is
> unchanged?

You may give it a try, I'm not sure exactly what you mean.

>>> Consequently, I expect
>>> followsymlinks="false" skipsymlinks="false" to behave as
>>> followsymlinks="false";

>> which would be the same as skipsymlinks="true", right?

> No, under the new proposal that would include the symlinks as symlinks, not
> files or directories.

Where would DirectoryScanner put those included symlinks?

> in the meantime, would it make sense to document what "followsymlinks"
> means in FileSet and what "followsymlinks" means in selectors that
> permit the attribute?

We must document that, I'd say :-)

> There are other issues, like support for symlinks in archives (JRE does not
> support them in
> zip files [1], rather one -- like Gradle [2] -- must use Commons Compress).
> Actually, there are a couple
> of old Bugzilla issues addressing symlinks [3, 4] :-).

I know Commons Compress pretty well ;-) and it doesn't really support
symlinks in archives either. Given that Ant's zip package is the parent
of Compress' zip support we should be able to do whatever Commons
Compress can do here as well. There is a good reason why we don't use
java.util.zip at all.

> So, what's the plan?

It's your itch, what is your plan? :-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx