Re: [boost] [modular boost] non-linked headers

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.