When I try to 'darcs add' the linux kernel with darcs-unstable on win32 I get 
this:

$ /c/darcs/darcs.exe add -r COPYING CREDITS Documentation/ Kbuild MAINTAINERS M
akefile README REPORTING-BUGS arch/ block/ crypto/ drivers/ fs/ include/ init/ 
ipc/ kernel/ lib/ mm/ net/ scripts/ security/ sound/ usr/ +RTS -p -RTS
darcs.exe: _darcs/patches/pending.new: renameFile: permission denied 
(Permission denied)

I tried to create a minimal test case to reproduce this and I have not succeded 
yet.  But it seems to happen every time on the linux kernel tree even if I 
delete _darcs and try again.

On Thu, Oct 19, 2006 at 08:05:18 +0000, Jason Dagit wrote:
> When I try to 'darcs add' the linux kernel with darcs-unstable on win32 I get 
> this:
> 
> $ /c/darcs/darcs.exe add -r COPYING CREDITS Documentation/ Kbuild MAINTAINERS M
> akefile README REPORTING-BUGS arch/ block/ crypto/ drivers/ fs/ include/ init/ 
> ipc/ kernel/ lib/ mm/ net/ scripts/ security/ sound/ usr/ +RTS -p -RTS
> darcs.exe: _darcs/patches/pending.new: renameFile: permission denied 
> (Permission denied)

I could not reproduce this under Windows (also MSYS).  I was using
1.0.9rc2.  I downloaded a copy of the kernel, and did darcs add -r *.
That seemed to work (although recording took such a long time that I
eventually just gave up in the middle).

What do you think we should do?  Shall we just close this bug?

On Sun, Dec 24, 2006 at 02:24:13PM +0000, Eric Kow wrote:
> On Thu, Oct 19, 2006 at 08:05:18 +0000, Jason Dagit wrote:
> > When I try to 'darcs add' the linux kernel with darcs-unstable on win32 I get 
> > this:
> > 
> > $ /c/darcs/darcs.exe add -r COPYING CREDITS Documentation/ Kbuild MAINTAINERS M
> > akefile README REPORTING-BUGS arch/ block/ crypto/ drivers/ fs/ include/ init/ 
> > ipc/ kernel/ lib/ mm/ net/ scripts/ security/ sound/ usr/ +RTS -p -RTS
> > darcs.exe: _darcs/patches/pending.new: renameFile: permission denied 
> > (Permission denied)
> 
> I could not reproduce this under Windows (also MSYS).  I was using
> 1.0.9rc2.  I downloaded a copy of the kernel, and did darcs add -r *.
> That seemed to work (although recording took such a long time that I
> eventually just gave up in the middle).
> 
> What do you think we should do?  Shall we just close this bug?

I suppose it depends if Jason can reproduce it.
-- 
David Roundy
http://www.darcs.net

I encountered a similar issue with a large number of files using darcs-1.0.8 and
darcs-1.0.9rc compiled on my machine. The issue may be Autoconf.use_mmap.
read_pending uses gzReadFilePS, which does mmapFilePS if Autoconf.use_mmap is
True. I was able to 'fix' the problem by setting use_mmap to False.

I would suspect, without having checked the mmap code, that if pending.new is
small enough it doesn't get mapped by mmap, or somehow gets mapped
'differently', otherwise it gets mapped and then Windows won't let you rename
the underlying file. When I tried added files one at a time, I got the error
when growing pending from 16228 bytes to 16419 bytes, suspiciously around 16k.

[revising related issue number]

Jason, did you use configure --disable-mmap? I had a similar problem in
issue443, and found that disabling mmap (which incidentally the build
instructions in the manual call for) solved the issue.

Thanks to dhunt for pointing this out.  (To be honest, I don't know what this
mmap stuff is about)

I haven't tried this for a while, but I'll see if I can reproduce it.
Back when I noticed this I didn't try --disable-mmap.

Jason

On 7/16/07, Eric Kow <bugs@darcs.net> wrote:
>
> Eric Kow <eric.kow@gmail.com> added the comment:
>
> [revising related issue number]
>
> Jason, did you use configure --disable-mmap? I had a similar problem in
> issue443, and found that disabling mmap (which incidentally the build
> instructions in the manual call for) solved the issue.
>
> Thanks to dhunt for pointing this out.  (To be honest, I don't know what this
> mmap stuff is about)
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue320>
> __________________________________
>
>

And it seems that I no longer have a viable windows test box to try this on.

If disabling mmap solves the problem, should mmap always be disabled
on win32 as per the default?

Jason

On 7/18/07, Jason Dagit <bugs@darcs.net> wrote:
>
> Jason Dagit <dagit@codersbase.com> added the comment:
>
> I haven't tried this for a while, but I'll see if I can reproduce it.
> Back when I noticed this I didn't try --disable-mmap.
>
> Jason
>
> On 7/16/07, Eric Kow <bugs@darcs.net> wrote:
> >
> > Eric Kow <eric.kow@gmail.com> added the comment:
> >
> > [revising related issue number]
> >
> > Jason, did you use configure --disable-mmap? I had a similar problem in
> > issue443, and found that disabling mmap (which incidentally the build
> > instructions in the manual call for) solved the issue.
> >
> > Thanks to dhunt for pointing this out.  (To be honest, I don't know what this
> > mmap stuff is about)
> >
> > __________________________________
> > Darcs bug tracker <bugs@darcs.net>
> > <http://bugs.darcs.net/issue320>
> > __________________________________
> >
> >
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue320>
> __________________________________
>
>

On Wed, Jul 18, 2007 at 14:41:56 -0000, Jason Dagit wrote:
> If disabling mmap solves the problem, should mmap always be disabled
> on win32 as per the default?

Well, since the doc asks for it,  I think it would be fair for the
configure script to set it that way.

Resolved in unstable

Fri Oct 26 01:57:30 CEST 2007  Eric Kow <eric.kow@gmail.com>
  * [issue320] Disable mmap under Windows.