$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [modular boost] non-linked headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-03 01:31:53
On 12/2/2013 10:47 PM, Gavin Lambert wrote:
> On 3/12/2013 16:34, Quoth Edward Diener:
>> A tool wants to replace this file's data and in doing so it attempts to
>> delete it and then recreate it with the same name. The 'delete' would
>> reduce the reference count to 1. What happens then when the file gets
>> 'created' with the same name ? By create we can also consider 'copy' or
>> 'move' to that same name:
>>
>> 1) The file create fails
>> 2) The file create actually change the file which still exists and
>> increases the hard link reference count to 2
>>
>> If it does 1) as I suspect, than using the hardlink fails with such a
>> product. If as another poster has ascertained 'git' uses the 'delete'
>> and 'create' method to change the file to a different version, then
>> 'git' will fail. The same goes for any tool that changes the file by
>> deleting it and recreating it if 1) is how things work with hardlinks.
>> OTOH if 2) is the case then there are no problems.
>
> No, that's not how it works.
>
> If the file is deleted, the reference count of the *other* copy of the
> file will go down to 1, and in the local directory there will be no file.
>
> If a file with the same name is then created (whether via write, copy,
> or move), this will succeed but result in an independent file that is
> not associated with the "other" file at all; changing one will not
> affect the other.
That sounds right. It was my confused thinking about what a file entry
in a file system is that posited those ridiculous other possibilities.
That still proves that in the face of any tools, which recreate a file
when the file is updated, using a hard link as opposed to a symbolic
link is the wrong thing to do if you want the hard links to refer to
the same file data.
>
> In order to "fix" this, something would have to go through and
> explicitly recreate the links, possibly inspecting each of the copies to
> determine which one is "better". (Or be configured to always steamroll
> one way or the other.)
IMO way too much work unless there is no symbolic links on an OS as an
alternative to hard links.