Proposal: removeDirectoryRecursive should not follow symlinks

[Greg Weber]

We all agree that we should do something about this. For 99% of use cases
this is a bug fix.
So I would like to just leave it up to the implementer to decide what to do.


On Wed, Jan 7, 2015 at 9:49 AM, Gabriel Gonzalez <gabriel439 at gmail.com>
wrote:

>  Actually, I might retract my recommendation to provided it under a
> different name.  I'm neutral on this now and would consider it okay to
> change in place.
>
> My reasoning is that this is a bug fix, so we can reasonably expect users
> to put lower bounds on software in response to bug fixes like we do with
> other software.
>
>
> On 1/7/15, 1:47 AM, Johan Tibell wrote:
>
> I don't think so but if we change the function signature or name as some
> suggested it all needs to be cpped still.
> On Jan 6, 2015 9:39 PM, "Erik Hesselink" <hesselink at gmail.com> wrote:
>
>> Does cabal rely on this behavior?
>>
>> Erik
>>
>> On Tue, Jan 6, 2015 at 9:37 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 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
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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/20150108/a4ed4d89/attachment-0001.html>