[darcs-users] DeleteFile on Windows (was: Re: hashed-storage work now merged in (woo!))

[Jason Dagit]

Thanks Petr.  I'm trying to wrap my head around this so I have some
questions.

On Thu, Oct 8, 2009 at 3:17 PM, Petr Rockai <me at mornfall.net> wrote:

> Hi,
>
> Eric Kow <kowey at darcs.net> writes:
> > So you may have noticed me saying this in a couple of recent threads.
> > Petr Ročkai's hashed-storage work from his 2009 Google Summer of Code
> > project has been merged!
> >
> > I thought I would take a few moments to give everybody an overview of
> > how this work benefits us, and where we'll be going in the future.
>
> before we can really celebrate, there're some issues that we need to sort
> out. Unfortunately, darcs has regressed a fair bit on win32, as our current
> red
> Windows slave witnesses. I can reproduce some of these failures on my
> virtualboxed Windows XP, but not even all of them. It won't be easy to fix,
> either. I suspect part of the problem is in more aggressive mmapping -- in
> fact, we now mmap pristine on Windows, which was never before the case, as
> far
> as I can tell.
>
> The mmap package in its current incarnation uses C finalizers for mmap'd
> areas,
> but that doesn't seem to be enough to get the mappings finalized soon
> enough
> (with regards to deleting files in pristine).
>

I want to see if I understand the situation correctly.

* On POSIX even if a file is open you can write over it, on windows this is
not the case
* mmaping a file keeps it open until the memory is unmmaped
* finalizers are used to unmmap the memory, and hence unlock files on
windows
* GHC is allowed to delay finalizers all the way until the program has
terminated and the RTS is cleaning up



>
> -- | Remove a file. On POSIX, this is alias to removeFile. On Windows, we
> try
> -- to removeFile first, but if that fails with permission problems
> (probably
> -- still open), we instead move that file into the trash location set using
> -- "setTrashLocation".
> trashFile :: FilePath -> IO ()
> trashFile = undefined
>

This appears to assume:
* On windows you can move a file even if it is open

Is that assumption true?

What about telling GHC to run any pending finalizers before trying to remove
files?

Can we be absolutely sure that windows doesn't have some sort of extended
file system api that allows the semantics we need?  What if this isn't the
real problem?  How did you determine that it was the finalizers at fault?

Thanks,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20091008/6e706742/attachment.htm>