On 2020-12-27 18:02:44 [+0100], Vincent Lefevre wrote: > On 2020-12-27 15:47:05 +0100, Sebastian Andrzej Siewior wrote: > > xz refuses to decompress a file which has more than one hard link. It > > can be reproduced byi (as per Vincent): > > |$ echo foo > file1 > > |$ xz file1 > > |$ ln file1.xz file2.xz > > |$ xz -d file1.xz > > |xz: file1.xz: Input file has more than one hard link, skipping > > Note that when I reported the bug, I used the -k option (without > it, I may understand the reason why xz refuses the operation with > more than one hard link, because removing the link will lose some > information: the fact that 2 files were hard-linked).
Indeed, I lost -k option. So without removing the file it actually makes no sense. But yes: you lose the hard-link count but I don't see why this is important. > > This behaviour is consistent with `gzip' and `bzip2' but it is not > > documented. The `--force' option would ignore this restriction. > > > > I traced it back in `gzip' to the 90s but the change was not documented > > as such. It was moved, altered but not documented. At some point the > > error was restricted to <= 2 which might be related to disk quota. > > I don't see why disk quota would have an influence: whatever > the number of link counts, a new file (the decompressed one) > is created. My understanding is that the first file is accounted on users' quota and the hardlink (by another user) isn't. If the user, that had the file accounted, removes the file then it gets accounted on the disk quota of the other user which may exceed the his quota. I never used disk quota, this a story I remember from back then. Sebastian
