Boost logo

Boost :

Subject: Re: [boost] [modular boost] non-linked headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-02 22:34:33

On 12/2/2013 9:02 PM, Beman Dawes wrote:
> On Mon, Dec 2, 2013 at 7:11 PM, Daniel James <daniel_at_[hidden]> wrote:
>> On 3 December 2013 00:08, Bjørn Roald <bjorn_at_[hidden]> wrote:
>>> yes, but b2 headers create hard links
>> It really should use soft links. Most programs don't change files in
>> place, so as soon as such a change is made the two entries will be
>> pointing to different inodes. Which defeats the purpose, since they
>> should always be the same.
> I'm missing something. Could you give an example of what you mean by "Most
> programs don't change files in place"? Hard links ensure that a change is
> always seen by both the entries because there is only one underlying file.
> I ran into that with Visual Studio when I tried symlinks and found that as
> a result Visual Studio failed to realize when a dependency had changed.

Let us suppose there is a particular file AAA somewhere with a hard link
reference count of 2, meaning that there are 2 hard links to the file
from different places in the file system.

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at