Re: [PATCH v3] Add an option not to use link(src, dest) && unlink(src) when that is unreliable

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 27, 2009, 16:11 UTC
Message-ID: <alpine.DEB.1.00.0904271800360.7741@intel-tinevez-2-302>
In-Reply-To: <alpine.LFD.2.00.0904270806130.22156@localhost.localdomain>

Hi,

On Mon, 27 Apr 2009, Linus Torvalds wrote:

Show 12 quoted lines

> On Mon, 27 Apr 2009, Johannes Schindelin wrote:
> > 
> > So, force the use of rename() instead of the link() && unlink() 
> > incantation on Windows, and for good measure, add a 
> > core.unreliableHardlinks option to optionally force it on other 
> > platforms, too.
> 
> Ok, so:
> 
> 	Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> but I do think it could be improved. See below..

Sorry, I missed the fact that Junio already applied and pushed it to 'next'.

Show 12 quoted lines

> > 	Junio, do you want me to remove the config variable?
> 
> I'd keep it. But I'd suggest that the naming is odd. Why talk about 
> "unreliable hardlinks", when that's just a particular symptom. Why not 
> just talk about whether hardlinks should be used or not?
> 
> And to avoid double negative, make it
> 
> 	[core]
> 		usehardlinks = true/false
> 
> and then default it to 'true' for Unix.

Or maybe core.preferRenameOverLink?  Then we have no negation either.

Show 5 quoted lines

> The thing is, maybe people would prefer to use 'rename' over the 
> link/unlink games even on some unixes, and not because of 'reliability' 
> issues, but because they may have some filesystems that don't do 
> hardlinks, and they'd just rather speed things up by avoiding the 'link()' 
> system call that will just error out.

We already fall back to renaming when another error than EEXIST is returned from link(), so I think this case is covered.

Show 7 quoted lines

> So naming matters. Calling it 'unreliablehardlinks' in that case would 
> be odd. They're not unreliable - you just don't want to try to use them.
> 
> I also do wonder if we could/should make this one of those options that 
> get set automatically at 'git init' time, rather than silently hardcoded 
> as a compile option. I thought hardlinks at least sometimes worked fine on 
> Windows too, don't they?

I thought about that long and hard, and I decided against it. Take my NTFS-formatted portable hard drive (for convenience with Windows users @work) for example: the ufsd driver is totally broken, but because it is a major investment of time to get my EeePC to work with a sane Linux distribution, I'd rather keep using the ufsd driver. Yet, when I use ntfs-3g from the other laptop, it works fine.

See?  It is not a file system specific error, but a fs/os combo problem.

> I do detest _hidden_ default values for config options, unless those 
> hidden defaults are "obviously always correct" as a default. This one 
> smells a bit uncertain, and as a result I think it's ok to default to 
> not using hardlinks, but doing it with .gitconfig would be nicer.

I fully agree on hidden default values, albeit in this case, it is necessary: the hard links work just fine on Windows XP here, but that might just be a matter of not upgrading to a newer service pack.

Ciao, Dscho