My basic setup is this: the (single) computer is running Windows 7,
has access to a number of network shares (Windows DFS), and runs
Debian inside a VirtualBox virtual machine. I'd like to use darcs on
both Windows (with cygwin installed) and Linux, with the "remote"
repository that I push/pull to/from being on one of the network drives
(crucial!). I can connect to Windows from Linux using ssh (there is an
sshd running within cygwin). The network share is also available to
Linux as a shared folder, and is mounted.

Here's what I've done: I used cabal to install darcs-2.5.2 on Linux
(Debian testing only has 2.4.x pre-packaged) and did the same on
Windows (with Haskell-2011.2.0.1, with -f-curl).

If I make a new darcs repository on Linux and "put" it directly to the
mounted VirtualBox shared folder, which in turn is a Windows network
share, I get this:

  > darcs put /share/tmp/test
  darcs: _darcs/index: mmap of '_darcs/index' failed: invalid argument
(Invalid argument)

If I use ssh to log into the Windows host and invoke the darcs-2.5.2
Windows binary, then the "put" succeeds:

  > darcs put windows:S:/tmp/test

This also creates a repository on the network share which contains all
the files. Now the "push" command fails, though:

  > darcs push
  ... interactive blabla ...
  darcs.exe: _darcs/index: MoveFileEx "_darcs/index" "_darcs/index.old":
permission denied (The process cannot access the file because it is
being used by another process.)

If I, just for curiosity, "get" the repository purely within Windows,
using the darcs-2.5.2 Windows binary invoked from within a cygwin
shell, that also appears to work fine, until I make changes ("rec")
and try to "push" them back:

  $ darcs push
  ... interactive blabla ...
  Shall I push this patch? (1/1)  [ynW...], or ? for more options: a
  Apply failed!

That's it, no more verbose errors.

Interestingly, if I run this command again, I get this:

  darcs.exe: _darcs/index: MoveFileEx "_darcs/index" "_darcs/index.old":
permission denied (The process cannot access the file because it is
being used by another process.)

just before the "Apply failed!", everything else remains the same.

I'm stuck. I made this bug "urgent" because this really stops me from
working. It's not just a rare occurrence, it completely stops the
show.

Any help would be greatly appreciated.

Hi, sorry to hear you're having trouble.  Unfortunately, we can't 
guarantee the kind of responsiveness you ought to get.  Sorry :-(

We can try to get you unstuck a bit (perhaps visit #darcs on 
irc.freenode.net) and as far as this ticket goes, this should be our 
first priority. Do I understand correctly that your goal is to be able 
to work on the Darcs repository in the Linux VM and push patches to the 
Windows host?  What's the simplest possible setup that would be useful 
to you?  In other words, how many variables can we cut to get you to a 
place where you have something that works well enough to get work done?

Can you try using darcs send -O to create a patch bundle, and running 
darcs apply on the other end to see if that succeeds?

I've just done more tests: what I find is that if I get rid of the
Windows DFS share to hold the repository, then all problems go
away. That is, if in place of the network share, I use the local
harddrive (C: or so) to hold the "remote" repository, then everything
works. This isn't much help for me (I need it to be on that network
share), but maybe it's a good starting point.

Since, as it now appears, darcs on Windows has problems with the network
share even without Linux being involved, I'm not sure the manual patch
transfer would work, but I can try anyway.

Hmm, I just noticed that you may be experiencing issue1759, so I'm going 
to close this as duplicate.

(it gets a bit confusing in the end because somebody posted an unrelated 
bug at the end of the bug)

Have you found a solution that would let you get work done?  I would 
suggest getting in touch with darcs-users to see if anybody on the list 
has ideas for how to make this practical.  Perhaps some sort of rsync-
based solution to mirror the repository between a local hard drive and 
the network share?  Also, it could be worth having a look around to see 
if other DVCSes support repositories on network shares better.  Sorry :-
(

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.

This is with the 2.5.2 Windows release of darcs, and VirtualBox
3.2.8_OSE r64453 on an Ubuntu 10.10 host.

"issue1759 looks like a file is locked by another process, whereas the
message in issue2091 doesn't say anything about that"

I should have said, some of the error messages in issue2091 say that,
but some don't (the "invalid argument" message).

Oh, I see what the pattern is. The writes to a mounted VirtualBox shared
folder (accessed from either Windows or Linux) fail with an "invalid
argument" error, and the writes to a Windows network share (again, from
either Windows or Linux) fail with "permission denied (The process
cannot access the file because it is being used by another process.)".
So there are probably two bugs here, but issue2091 involves both.

Davidsarah, thanks.  I'd completely forgotten about the "invalid 
argument" error trying to scrutinise this bug.

Also people following this list should take note of the recurring 
"VirtualBox shared folders" as a common use case.  It should also make 
it a bit easier for us to reproduce, as less exotic.

Well, the problem is that virtualbox shared folders are a pretty bad 
implementation of an already bad filesystem interface. I don't think we 
can do anything about this: memory-mapping drives on virtualbox shared 
folders simply does not work. The only alternative is to read the index 
into memory with "read". Since virtualbox shares is about the only 
filesystem with any non-negligible amount of use that fails to support 
memory mapping, there isn't enough pressure to implement alternative 
index reading code just for this single case. I believe even standard 
network shares on windows do work (there may be other bugs, but memory 
mapping should be OK).

Possibly related to http://www.virtualbox.org/ticket/819 , in particular
see the comment by josephusm with the C code (search in page for
"josephusm"). He says:

"When files are opened read-only and used with mmap() it works fine, but
it fails for files opened read-write and later used with mmap for writing."

That seems consistent with the failures I saw only being for operations
that write to files in a repository on a vboxfs share.

Any news on this item? It's a real shame that placing a respository on a
Windows DFS share breaks darcs. I've been updating the remote repository
from a local intermediate one using rsync, but this is complicated and
error-prone. Does darcs really use such fancy filesystem access that it
doesn't cope with a DFS share?

I think the VirtualBox issue is secondary and much easier to work around.

No developments to my awareness, I'm afraid :-(

It'd be great if we could have a http://wiki.darcs.net/Internals 
documentation on what Darcs needs from the filesystem and why.

Is there anything I can do to help?  Some testing, logs, etc., to help
get this issue fixed?