Proposal: removeDirectoryRecursive should not follow symlinks

[Gabriel Gonzalez]

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 
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:Libraries at haskell.org>
>     >>>> http://www.haskell.org/mailman/listinfo/libraries
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Libraries mailing list
>     >>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >>> http://www.haskell.org/mailman/listinfo/libraries
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Libraries mailing list
>     >>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >>> http://www.haskell.org/mailman/listinfo/libraries
>     >>>
>     >>
>     >> _______________________________________________
>     >> Libraries mailing list
>     >> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >> http://www.haskell.org/mailman/listinfo/libraries
>     >>
>     >
>     >
>     > _______________________________________________
>     > Libraries mailing list
>     > Libraries at haskell.org <mailto: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/20150107/b1628ddc/attachment-0001.html>