TortoiseHg

On Mon, Oct 31, 2011 at 9:22 AM, Robert Kochem <robert@...> wrote:
> Hi.
>
> I am using TortoiseHG 2.1.3 on Win64 and have serious problems because hg
> operations (commit, pus, pull) often fail.
>
> The error message is always the same: "The process cannot access the file
> because it is being used by another process."
> Unfortunately hg does not tell which file is affected.
>
> The only way to make hg work again is to kill ever Explorer.exe process.
> Therefore this seems to me like a problem in the shell extension which
> locks file handles and does not release them properly.
> IMHO the shell extension should release file handles as fast as possible.
> Additionally all calls to the CreateFile Win-API function should specify
> dwShareMode as FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE so
> that it does not block any other process.
>
> Robert
>
> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
> (v=vs.85).aspx

The GUI windows use a QFileSystemWatcher instance to watch the
repository for changes.  Over network disks, this causes problems like
you're reporting.  A few releases back we added a configuration option
to only watch for file system events on local disks.

-- 
Steve Borho

Hallo Robert

Funny domain name :-)

On 2011-10-31 15:22, Robert Kochem wrote:
> Hi.
> 
> I am using TortoiseHG 2.1.3 on Win64 and have serious problems because hg 
> operations (commit, pus, pull) often fail. 
> The error message is always the same: "The process cannot access the file 
> because it is being used by another process."
> Unfortunately hg does not tell which file is affected.

...

> The only way to make hg work again is to kill ever Explorer.exe process. 

Any virus scanners running?

Other shell extensions?

> Therefore this seems to me like a problem in the shell extension which 
> locks file handles and does not release them properly.

Are you sure your analysis is correct?

Did you check how the shell extension accesses files?

> IMHO the shell extension should release file handles as fast as possible.
> Additionally all calls to the CreateFile Win-API function should specify 
> dwShareMode as FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE so 
> that it does not block any other process.
> 
> Robert
> 
> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
> (v=vs.85).aspx

This should already be the case since:
https://bitbucket.org/tortoisehg/shellext/changeset/3546bb81cf63

In effect since June 2009

The shell extension only reads the files .hg/dirstate and .hg/thgstatus

For files in the working dir (=tracked files), the shell extension is
only doing "stat" calls via win32 API FindFirstFileW and FindClose:

https://bitbucket.org/tortoisehg/shellext/src/ff667fa17d23/src/Winstat.cpp#cl-21

Using the FindFirstFileW / FindClose pair has proven to be the fastest
way get stat data (modification time etc).

Adrian

Steve Borho wrote:

> The GUI windows use a QFileSystemWatcher instance to watch the
> repository for changes.  Over network disks, this causes problems like
> you're reporting.  A few releases back we added a configuration option
> to only watch for file system events on local disks.

I assume you are referring to the setting "Monitor Repo Changes" which can 
be changed to "localonly", right?

Robert

[1] https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-
network-share