Proposal: removeDirectoryRecursive should not follow symlinks

[David Feuer]

This seems reasonable, but if we have a deprecation cycle, the old name
should (temporarily) be a synonym for the new one, and the deprecation
warning should indicate that code intended to work with older versions
needs to be audited.
On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:

>  I think it's safer to remove the old function altogether (perhaps after
> one deprecation cycle) and provide a new one under a different name, rather
> than modify it in place.
>
> Modifying it in place risks the behavior that others mentioned where your
> program is unsafe to compile against older library versions.  Yes, the user
> could explicitly enforce that by putting a lower bound on the library, but
> most users won't even realize that they need to do that.
>
>
> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>
> I'm +1 for fixing this, in place, on the current function.
>
>  The specification we have here is doing a very very bad thing and needs
> to be fixed, not slavishly copied forward because someone sometime once
> made a mistake.
>
>  The current behavior grievously violates the expectations of anyone who
> would be in a situation to go and reach for it and has any prior experience
> with any other such tool.
>
>  -Edward
>
>
>
> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com>
> wrote:
>
>>
>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>
>> > On 2015-01-06 14:57, Mike Meyer wrote:
>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>> >>
>> >>> This is not a bugfix. A bug is failing to follow the functions
>> >>> specification, which *does* include following symlinks.
>> >>>
>> >>
>> >> It's a bug in the design, not the code.
>>
>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>> > they think they do, they *really* don't.
>>
>> I agree 100%.  Even time I use this function, I worry briefly about
>> whether it follows symlinks, then think to myself "no, no-one would be so
>> stupid to implement that deliberately in a publically available API".  So
>> it was a real shock to discover in this thread that I was wrong, and
>> furthermore that the function is documented as doing the wrong thing.  We
>> should fix both spec and implementation, as soon as possible.
>>
>> Regards,
>>     Malcolm
>>  _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> 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/20150106/9312d2ae/attachment-0001.html>