Re: Proposal: removeDirectoryRecursive should not follow symlinks

On Mon, Jan 5, 2015 at 5:28 PM, Brandon Allbery wrote:

On Mon, Jan 5, 2015 at 8:22 PM, Eric Mertens wrote:

...

I'm concerned that changing the behavior of the existing function would make it too easy to write vulnerable programs when compiled with older GHCs. Having a new safe function along with a deprecation warning on the old one would clue people in and avoid functionality varying subtly/dangerously based on the compiler used.

Only really helpful if you can go back and retrofit that deprecation into already deployed older versions. Also, it's using the obvious name for the function. So the correctly working one needs to have some unobvious name and a 'warning you should not use this, use some_other_function instead' form this point on?

I don't know why 'removeDirectoryRecursive' would be considered by someone to be the only obvious name available. `removeDirectoryTree` would work also. Also, the warning does not have to be placed on older versions for it to have effect with older versions. The point is that the library author will be taught not to use this function at all. When I suggested deprecation, I assumed that following a symlink was a desirable behavior for someone. If it is not and it is 100% the case that this behavior is a defect, then this is just a bugfix then deprecation is not needed. However, since this is considered dangerous, I think Eric makes an excellent point that it makes it possible for the function to be used properly for one compilation of a library that depends on `directory`, but for another compilation to pick up an older version of `directory`. That means that just fixing the behavior in the newest version of `directory` is not very satisfactory. So I see 2 approaches to address these issues 1) the deprecation warning approach 2) produce an updated point releases with the bugfix for every major version of directory. It still could be a good idea to do the deprecation warning on top of this because there are still older versions of the function out there with the bad behavior.

Indeed, the Java community does do things that way. One of many reasons the Java ecosystem is an absolute, irredeemable mess.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries