design question, why not always use 'cp --remove-destination'?

[Frederik Eaton]

Perhaps the "Text file busy" error is Unix-specific, but I can imagine
cases where somebody (other than the OS) might open a file with a
well-known name and read from various parts of it, and expect it not
to change underneath them...

Regards,

Frederik

On Tue, Aug 22, 2006 at 05:19:42PM +0300, Krasimir Angelov wrote:
> Isn't this Unix specific bug? If that is the case then maybe unlinking
> should be optional.
> 
> Cheers,
>   Krasimir
> 
> On 8/22/06, Frederik Eaton <frederik at a5.repetae.net> wrote:
> >Dear bug-coreutils,
> >
> >We are trying to decide what the semantics of the Haskell standard
> >library function 'copyFile' should be. The first incarnation behaved
> >roughly like 'cp', i.e. overwriting destination files without
> >unlinking them first. This isn't suitable for installing stuff, for
> >example, since if an executable is running and we try to overwrite it
> >then there is a "Text file busy" error. We could change the semantics
> >to be the same as 'cp --remove-destination', i.e. unlinking
> >pre-existing destination files.
> >
> >The question is, is there a reason why users wouldn't always want a
> >"copyFile" function to remove the destination first? If there is, then
> >maybe we should have two separate functions, for both situations. The
> >only drawback I can think of for removing the destination first, is a
> >race condition when someone else is trying to create the same file,
> >but how often does that actually become a problem?
> >
> >Thanks,
> >
> >Frederik
> >
> >--
> >http://ofb.net/~frederik/
> >_______________________________________________
> >Libraries mailing list
> >Libraries at haskell.org
> >http://www.haskell.org/mailman/listinfo/libraries
> >
> 

-- 
http://ofb.net/~frederik/