Proposal: removeDirectoryRecursive should not follow symlinks

[Greg Weber]

On Mon, Jan 5, 2015 at 5:28 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Mon, Jan 5, 2015 at 8:22 PM, Eric Mertens <emertens at gmail.com> 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 at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/f0c36f60/attachment.html>