I discovered the hard way that if I use <delete> to delete a temporary directory created by the build then I must be very careful not to create symbolic links, for test purposes say, to directories outside of my test data. I lost about 6 hours recovering and only because I had a fairly recent backup. It wasn't that I was completely stupid ;-) but that I made a series of changes none of which introduced obvious risk. I consider this a bug because this sort of thing does not happen with other tools available on platforms that support symbolic links. I believe it was introduced sometime since August judging by ant-dev archive. I have a patch that uses utils/FileUtils in taskdefs/Delete.java to check that a directory is not a symbolic link before descending into it, but I am not sure of issues such as backward compatibility. I suggest it might be optional but the default should not descend such links.
I will wait for comment from "insiders" before submitting my trivial patch. The other issue is perhaps interpretion of filesets etc. One never actually wants to follow symbolic links outside of the directory being deleted - that's the other main reason this is a bug and not the behaviour of native tools. The other part of the fix might be an appropriately worded warning in the docs because even if symbolic links are recognised, if you export a Linux file system using SAMBA and compile under windows, they will not be recognised. Ant being crossplatform, that is exactly the sort of thing one might want to do.
I'd be very interested in your "trivial patch" when it comes to the samba and Windows issue you describe. How do you detect a symlink on a samba shared drive from within Java? For backwards compatibility Ant will have to follow symlinks by default. Does delete follow them if you set the followsymlinks attribute to false on your filesets?
I suspect that this is a duplicate of 1550 is it not?
Yes this looks like a duplicate of 1550 which was fixed. My suspicion is that it has been reintroduced. Regarding my patch, it is not only trivial but probably insufficient which is why I have not submitted it and the point I was making Stefan. You made it even better! (Also, it looks more complicated than it is due to increased indentation inside new if statement.) I'm not sure about this backward compatibility issue, especially if 1550 was recently re-introduced. It seems to me you have to balance this with the question of whether it does the right thing by default. Few people if any will be relying on it doing the wrong thing but many more may end up deleting their data accidentally. So I still think, change the default, possibly add new features and put a warning in the docs re SAMBA etc. I will look into followsymlinks on filesets if I find time. Regards
Sorry, original comments about bug being introduced since August were probably wrong. There is some discussion about something similar here: http://marc.theaimsgroup.com/?l=ant-dev&m=102953577003770&w=2 but no sign of any such changes in taskdefs.Delete.removeDir(File) or exec(). My <delete> task was <delete dir="test/unit/output"/> and I haven't tried a fileset but think that even if there is a way of not deleting symbolic links, it is still a bug. It seems to me that any cases where you want to follow a symbolic link to directory and delete files (because you are not picking them up directly) are very obscure.
Well, it all is about backwards compatibility, sorry. <delete dir="somedir"/> is the traditional way to say "delete this directory and all its contents, don't ask any questions. The kind of task you use when running a "clean" target. If you want to do anything more sophisticated, use nested filesets. <fileset> in turn didn't know about symbolic links until Ant 1.5 (as Java doesn't know about them and we are still not sure whether the code we use works for all operating systems - especially systems that are not Unix-like). To have the complete same semantics as Ant 1.4, the only possible choice for Ant is to follow symbolic links by default. <delete> is special in a certain sense - it supports an followsymlinks attribute (inherited by MatchingTask) but ignores it unless you've also specified some include or exclude patterns. This is going to be fixed in CVS in a few minutes. After that, <delete dir="foo" followsymlinks="false"/> is going to be close to what you want, but still not the default.
Yep, you spotted the one case that isn't obscure, as I did after sending last comment.And we don't want to get into "somedir/" versus "somedir" for a crossplatform tool. Assuming <delete dir="foo" followsymlinks="false"/> is in the docs then I'm happy. (I am anyway, because I won't make the same mistake again.) Thanks for your rapid response. We could still point out in the docs that it won't necessarily work, over networks etc. but the main thing is to draw attention to the issue by documenting the feature, as usual.