Proposal: removeDirectoryRecursive should not follow symlinks

[Eric Mertens]

There's no option which avoid needing to fix all packages on hackage, so
each maintainer using this function will be responsible for fixing his
packages.

If we fix it in place everyone needs to add CPP to avoid calling the broken
version on old versions of directory and use an alternative implementation.

If we make a new function everyone needs to conditionally call the new
function or use an alternative implementation.

On Tue, Jan 6, 2015, 12:38 PM Johan Tibell <johan.tibell at gmail.com> wrote:

> Who volunteers to fix the breakages in Cabal and add all the needed CPP?
>
> On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com> wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://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/fcccf58a/attachment-0001.html>