[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] in place option for unexpand

From: Sami Kerola
Subject: Re: [PATCH] in place option for unexpand
Date: Mon, 20 Apr 2009 21:59:42 +0200

On Fri, Mar 27, 2009 at 15:20, Sami Kerola <address@hidden> wrote:

> Well I changed rename to copy that is part of coreutils and use the
> call in move_mode. I did not send new patch because I want to be sure
> my employer has signed papers stating that they have no right to my
> contributions to coreutils. Perhaps I should wait copyright papers to
> get ready before making questions. It's a bit difficult to ask
> questions && get correct answers when you don't see what I am talking
> about.

Hello again,

My legal papers are ready to be sent to Boston. I'll be in touch with
GNU copyright personel tomorrow. Since it should be now safe to send
patches here is next one. Quite honestly I am not 100% happy about it.
The patch does quite much everything that you'd expect, but there are
two issues.

When backup is specified permissions and ownership of mkstemp file are
used. It would make more sense to use destination attributes, but the
copy.c does not support that. I tried write a patch which would do
that, but it was tricker than I expected. And if you think this is
right thing to do I'll invest more of my time to write such patch.

The message "The backup suffix is `~', unless..." should go to
lib/version-etc.c or somewhere similar. If in-place is implemented to
several command this sort of tactic should be nice to translators.

So what do you think, is the in-place implementation better or worse
when it uses copy.c?

   Sami Kerola

Attachment: 0001-in-place-option-that-uses-copy.c.txt
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]