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

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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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