On 2009-06-27 16:24 +0200, Jay Berkenbilt wrote:
> Package: quilt
> Version: 0.46-7
> Severity: normal
>
>
> /usr/share/quilt/scripts/backup-files, in the function process_file(),
> calls 'chmod 000 "$backup"' when adding a new file. This seems like a
> truly strange thing to do. Quilt already detects when the original
> file is empty and uses /dev/null as the old file in the diff. Why
> does it have to do a chmod 000 too? This causes things that copy
> source directories to fail because of the unreadable file.
I find this also quite annoying. The only explanation I have for this
strange behavior is that upstream is doing the same thing in their C
implementation and Steve Langasek just emulated that when he reworked
backup-files in bash.
Digging into quilt's upstream git repository, I found out this had been
the case since 2003¹. Here's the relevant part of the diff:
@@ -168,7 +169,8 @@ process_file(char *file)
if (!opt_silent)
printf("New file %s\n", file);
- if ((fd = creat(backup, 0666)) == -1) {
+ /* GNU patch creates new files with mode==0. */
+ if ((fd = creat(backup, 0)) == -1) {
perror(backup);
return 1;
}
WTF?!? I cannot remember ever having seen patch create new files with
mode 0, and certainly all kinds of things would break in interesting
ways if you could not read your just created files in source trees.
ISTM there is no rationale at all for making these files unreadable.
Sven
¹
http://git.savannah.gnu.org/cgit/quilt.git/diff/lib/backup-files.c?id=5b3c46d7f9cc3be46af00c556ea887f437dbeb04
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
