Proposal: removeDirectoryRecursive should not follow symlinks

[Johan Tibell]

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/1e8dc75b/attachment.html>