[Top][All Lists]

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

Re: [bug-patch] Time for a new release?

From: Jean Delvare
Subject: Re: [bug-patch] Time for a new release?
Date: Mon, 16 Apr 2012 19:21:41 +0200
User-agent: KMail/1.12.4 (Linux/; KDE/4.3.5; i686; ; )

Hi Andreas,

On Monday 16 April 2012 06:08:42 pm Andreas Grünbacher wrote:
> Jean,
> Am 16. April 2012 15:35 schrieb Jean Delvare <address@hidden>:
> > So with the latest version of GNU patch, every "quilt push" results
> > in a warning about read-only files. This is rather inconvenient and
> > passing --quiet doesn't even make it go away. And "quilt push -f"
> > fails. Bad.
> Why does "quilt push -f" fail?

This is somewhat unintuitive (I had to check the code twice myself) but 
"quilt push" calls "patch -f" while "push -f" calls "patch" (no -f). And 
new version of "patch" fails on read-only files unless forced, so now 
"quilt push -f" fails on read-only files.

Maybe we could use "patch -f" always, I'm not sure. But even then, 
"patch" now displays a warning message, which can't be suppressed, so it 
won't completely help.

> > I do agree that the previous behavior (silently operating on
> > read-only files by default) was wrong, but I think the new behavior
> > is wrong too. If I tell patch to operate on a read-only file with
> > --backup option (as quilt does), it would seem that I know what I'm
> > doing. So I think patching read-only files should be as silent and
> > successful as it used to be as long as --backup option is used.
> I really can't follow you here. Patch should behave consistently on
> read-only files, whether or not it creates backups.

Maybe this is twisted thinking from me, but I think --backup changes the 
semantics of what patch is doing, especially for read-only files. 
Without --backup, patch operates in-place on the file, so it changes it, 
which is not acceptable if the file is read-only. But with --backup, the 
original file is preserved, which complies with its read-only status, 
and I see the modified file as a new file (which may even not be read-
only, that wouldn't shock me.)

> > [...] we don't want to make files writable before they are unlinked
> > from the reference tree
> A "cp --reflink" copy would work, but that is not widely supported
>  yet.

It's not even supported on my own system. The whole concept is news to 
me. How does it work, hard link + extended file attribute which says 
"break the link on file change"? Can this mode be set afterwards?

>  Maybe we do need to let the user choose between the old and new
>  behaviour.

If you don't like my proposal to depend on --backup, then yes, I presume 
this is the way to go, although I'm not quite sure what this new option 
should be named.

Jean Delvare
Suse L3

reply via email to

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