Betr: Re: Re: Commit hook to find out who is holding a lock?

[Alban Hertroys]

Matt Mackall <mpm at selenic.com> wrote on 20/05/2015 19:18:59:

> 

alban.hertroys at apollovredestein.com
T: 




 	Apollo Vredestein B.V. - P.O. Box 27 - 7500 AA  Enschede - The Netherlands - 
Chamber of Commerce number 34223268 - http://www.apollovredestein.com	 

The information contained in this e-mail is intended solely for the use of the 
individual or entity to whom it is addressed and others authorized to receive 
it. You are hereby notified that any disclosure, copying, distribution or 
action in relation to the contents of this information is strictly prohibited. 
If you are not the intended recipient, please delete this message and any 
attachments and advise the sender by return e-mail. The confidentiality of this 
message is not warranted. Apollo Vredestein B.V. rules out any and every 
liability resulting from this or any other electronic transmission.
 
On Wed, 2015-05-20 at 14:46 +0200, Alban Hertroys wrote:
> > On Thu, 2015-02-26 at 17:03 +0100, Alban Hertroys wrote:
> > > > Hi all,
> > > > 
> > > > We're having an issue where files in our single shared repository 
are 
> > > > being locked by 'something' and we're trying to figure out what is 

> > causing 
> > > > this. The lock conflict only seems to happen on commits or 
updates, 
> > most 
> > > > often on commits. Meanwhile the files are being used (read) by a 
> > server 
> > > > process (tscom3, part of WebFOCUS) on the machine hosting the 
> > repository.
> > > 
> > > Is there an error message? Nothing in Mercurial does file-level 
locking.
> > > 
> > > However Windows has a notion of file exclusivity by default that it
> > > inherited from its misguided DOS + LanManager youth. Which means 
that
> > > when a poorly-written virus scanner (but I repeat myself) sees 
something
> > > touching a file.. it rushes in to check it and thereby locks you 
out.
> > > So.. probably a virus scanner.
> > 
> > I think I finally found the culprit. We use the keyword extension to 
add 
> > $Revision$ information to our code[*]. I just had one such locking 
issue, 
> > and in the physical file the string is still '$Revision$', but in the 
> > repository it has changed to '$Revision: 0e72bb884edf $'! Is that a 
> > plausable conclusion?
> 
> (You still didn't send your precise error message, so I'm still
> diagnosing based on a vague "something is being locked by something on
> Windows".)

I caught it using hg commit on the command line this time, here it is:

T:\ibi\apps\develop_examples>hg commit -m "Added conditional join example" 
.
abort: No such file or directory: 
T:\ibi\apps\.hg/store\journal.backup.fncache
transaction abort!
failed to recover fncache
rollback completed

The interesting bit is that in that directory there are no files 
containing '$Revision' (according to the somewhat unreliable explorer 
search for "*.fex content:$Revision", but in that directory it's probably 
correct).

> The usual "locking" problem on Windows is this:  if you have ANYTHING
> else on your machine (web server, database, IDE, virus scanner, backup
> program, whatever) that is opening these files at the same time
> Mercurial is, you will probably lose.
>
> That's because the DEFAULT for opened files on Windows is "exclude other
> processes from reading, writing, or deleting". And just about every app
> today still uses this default. Mercurial shares all files it opens, but
> this doesn't help if other apps don't. You can't fix the problem in
> Mercurial, you have to rewrite the other apps.

I'm aware that Windows is rather terrible at that. Try for example to edit 
and test an Excel 2013 template at the same time - you can't use the 
template to create a new sheet, because Excel has the template locked such 
that it can't even be read. You need to close the template (and lose your 
option of undoing changes) to be able to test it in a new Excel sheet. 
It's preposterous. Unfortunately it's what I have to work with.

> (Or switch to Unix.)

I'd love to, but there just aren't any people here (sufficiently) capable 
of, or willing to, provide support for such a system. I'm in the former 
group, our head sysadmin is in both and in the end it's his call.

Alban.