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

On 12/2/2013 9:02 PM, Beman Dawes wrote:

On Mon, Dec 2, 2013 at 7:11 PM, Daniel James wrote:

...

On 3 December 2013 00:08, Bjørn Roald 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.