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 <jdelv...@suse.de>: > > 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. Thanks, -- Jean Delvare Suse L3
