Hello Eric, I've tried the 2.4 windows binary from Salvatore, and
there is still a little bug.

The error message changed to:

Tue Mar  2 17:50:13 W. Europe Standard Time 2010  Luca Molteni <>
  * Patch prova
Shall I push this patch? (1/1)  [ynWsfvplxdaqjk], or ? for help: y
darcs: _darcs/index: MoveFileEx: permission denied (The process cannot
access the file because it is being used by anoth
er process.)
Apply failed!

The good news is that this happens in only one of my work's
repositories (on a network share on Windows), and deleting the
_darcs/index files all works without problems.

Maybe it happened because I used different versions of darcs.

I wonder if we can close the bug?


Bye,

L.M.



On 1 March 2010 14:17, Eric Kow <bugs@darcs.net> wrote:
>
> Eric Kow <kowey@darcs.net> added the comment:
>
> I just noticed this was still open will trying to look for things
> related to issue1753.  In case it was related.  Since this was a target
> 2.4 regression, I'm going to bump the urgency on it.
>
> Sorry, folks!  I should have been doing more issue management before
> this release :-(
>
> ----------
> priority: bug -> urgent
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue1728>
> __________________________________
>

I copied this from issue1728.  This seems fairly obscure and hard to
reproduce.  I think we should just wait and see if anybody else submits
a similar report.

The network share on Windows seems like an important variable.

Darcs 2.4 release. Doesn't work at all. To reproduce clean cache and run:

C:\Projects>darcs get http://modis.ispras.ru/src/sedna
darcs: C:\Documents and Settings\admin\Application
Data\darcs\cache/pristine.has
hed/0000001393-45b2ef897392615593d4af1a7cd02c9fb51fd789dfa291ed99fd15a7e72b30d8-
new_ff1d776eae193da59b9891ab1b03e9c0: MoveFileEx: permission denied
(▲B:070=> 2
4>ABC?5.)
Copying pristine 35 done, 16 queued. QuickStart

... hangs here and hangs if run it again (cache is not empty).

Thanks. How about the darcs-2.4.1 release?

It was 2.4.1 (I thought that build version number is not important). 
Now I have to use 2.2.0.

I've determined that msg10742 msg10747 and msg10779 belong on their own
ticket so I'm restoring this bug to its presumed-dead state and
continuing the discussion on issue1831

This got reported again on issue2091.  Looks like our first step is to 
reproduce difficulty using darcs on network shares under Windows.

I'm having a similar problem to issue2019, also involving VirtualBox
shared folders. When a Windows XP SP3 *guest* has a darcs repository on
a drive that is mapped to a Shared Folder (in this case to a filesystem
on the Linux host), then many operations that write to the repository
(such as 'darcs pull', but not all such operations, e.g. not the initial
'get') fail with an error like:

darcs: _darcs/tentative_hashed_inventory: hClose: invalid argument
(Invalid argument)

The path is not always '_darcs/tentative_hashed_inventory', but the rest
of the error is always the same.

When the same files are copied to a normal Windows drive on the guest,
the same operations work correctly. (This indicates that the files
weren't corrupted, it was just the access that failed on the shared folder.)

Note that although issue2019 was closed as a duplicate of this issue,
I'm not sure there was enough evidence to come to that conclusion. I
agree it is *plausible* that the same bug might affect both network
drives and VirtualBox shared folders, since both use the IFS driver
interface I think, albeit different drivers. However, the error messages
are quite different: issue1759 looks like a file is locked by another
process, whereas the message in issue2091 doesn't say anything about
that. Also, issue2091 seems to happen for all repositories, and deleting
_darcs/index makes no difference. So I think that these bugs should be
unduplicated unless and until there is more evidence that they are the same.

I should have mentioned that this is with the 2.5.2 Windows release of
darcs, and VirtualBox 3.2.8_OSE r64453 on an Ubuntu 10.10 host.

I meant issue2091, not issue2019. (Sorry for the multiple comment noise.)

No problem about the noise, davidsarah.  Folks (I mentioned this on 
issue2091), note the possibility of reproducing something like this error 
with the help of VirtualBox

I don't think issue1831 is related to this. Also, network shares and 
MoveFileEx error is a different story from virtualbox and invalid 
argument. The latter is just memory mapping of files not supported by 
virtualbox shares at all. The former is *probably* a problem with 
writing over recently deleted files. I don't think there's a fix other 
than adding a sleep between the delete and the move-over operations. 
Sucks, doesn't it? Welcome to wonderful world of Windows.

only small modification of existing idea described by mornfall:
other possible solution instead of "sleep for a while" before operation,
is to do operation but when this error happens, re-try after "sleep for
a while".