Re: Proposal: removeDirectoryRecursive should not follow symlinks

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" mailto:hesselink@gmail.com> wrote:

Does cabal rely on this behavior?

Erik

On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell mailto:johan.tibell@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 mailto:david.feuer@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" mailto:gabriel439@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 mailto:malcolm.wallace@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 mailto:johan.tibell@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@haskell.org mailto:Libraries@haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@haskell.org mailto:Libraries@haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@haskell.org mailto:Libraries@haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org mailto:Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org mailto:Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries