On 02/12/2013 11:52 PM, David Sterba wrote: > On Tue, Feb 12, 2013 at 07:01:33PM +0100, Goffredo Baroncelli wrote: >> On 02/12/2013 06:37 PM, Filipe Brandenburger wrote: >>> Hi, >>> >>> On Tue, Feb 12, 2013 at 8:39 AM, David Sterba <dste...@suse.cz> wrote: >>>> +# For backward compatibility, 'btrfs' changes behaviour to fsck if it's >>>> named 'btrfsck' >>>> +btrfsck: btrfs >>>> + @echo " [CP] $@" >>>> + $(Q)cp btrfs btrfsck >>>> + >>> >>> I think the idea was that btrfsck becomes a link (either symbolic or >>> hardlink works) to btrfs... >>> >>> Maybe just replace cp with ln? >> >> I agree with Filipe, or even a script is reasonable. So we have only one >> binary to update, and we avoid the risk to have a version mismatch >> between btrfsck and btrfs. This could lead to a different behaviour >> when the user call btrfsck instead btrfs. Finally this could save some >> bytes of space. > > Ok, I'll replace it with a hardlink. A symlink is not reliable (cannot > be copied without breaking the path).
...mmm... the install command (invoked by the Makefile during the installation phase) doesn't seem to preserve both the hard-link and the soft-link: $ touch test $ ln test test2 $ ln -sf test lntest $ mkdir t3 $ install test2 t3/ $ install lntest t3/ $ ls -li lntest test test2 t3/test2 t3/lntest 3005857 lrwxrwxrwx 1 ghigo ghigo 4 Feb 13 00:03 lntest -> test 3005858 -rwxr-xr-x 1 ghigo ghigo 0 Feb 13 00:03 t3/lntest 3005854 -rwxr-xr-x 1 ghigo ghigo 0 Feb 13 00:00 t3/test2 3005852 -rw-r--r-- 2 ghigo ghigo 0 Feb 13 00:00 test 3005852 -rw-r--r-- 2 ghigo ghigo 0 Feb 13 00:00 test2 I think that a bash script is a better choice. >> Anyway my opinion would be to left this kind to decision to the >> distribution. We (as upstream) should only remove the old btrfsck and >> issue an WARNING/REMARK in the release note to notify this change. >> Unfortunately btrfsck is old; now we must provide an alternative file to >> overwrite this binary in order to avoid the mismatch above when the user >> is used to recompile the binary from the source. > > A warning is a good idea and it will start a deprecation period of > btrfsck as separate utility. Unil some point in future, I'd rather stay > conservative and let it exist. > > david > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
