incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Windows support
Date Sun, 14 Jun 2009 21:49:34 GMT

On Jun 10, 2009, at 7:56 PM, Mark Hammond wrote:

> On 4/06/2009 3:27 AM, Damien Katz wrote:
>> I was once again reminded we need to add proper Windows support for
>> CouchDB when Mark Hammond provided a very nice patch to provide a
>> windows version of a couchdb unix script. (Thanks Mark!)
>
> Thanks!  Sorry I was a bit slow to see this thread.
>
>> But we also have some broken tests. Other than the issue Mark's patch
>> fixes, I think it's only compaction that's still broken.
>
> compaction and deletion are broken.  I've opened a bug on the delete  
> problem at https://issues.apache.org/jira/browse/COUCHDB-326, as  
> alisdair seemed to think that couch could have a simple change made  
> to allow 'delete' to work without changing how the files are opened.
>
> > I think the
>> cleanest way to fix that is to change the erlang VM to open db files
>> using flags to give them unix like semantics.
>
> I've learnt something about Windows file-systems today :)  My  
> experiments show that when using FILE_SHARE_DELETE:
>
> * A file can be deleted while it is in use - but another file of  
> that name can not be created until the handles are closed.
>
> * A file can however be renamed while it is in use, thereby allowing  
> the original name to be re-opened.
>
> If we consider the 'delete' case, then FILE_SHARE_DELETE may still  
> end up with a 'race' if an attempt to delete the DB is quickly  
> followed by a request to create it - the delete should succeed, but  
> the create will not.
>
> If we consider the 'compact' case, I *suspect* that couch will need  
> to rely on the ability to rename and replace rather than a simple  
> delete - so that might work fine.
>
> I'll have a bit of a dig around in the erlang sources and see what I  
> find, but of you have any other thoughts or pointers in the  
> meantime, please let me know.
>
> Cheers,
>
> Mark



Perhaps all files that get deleted (via explicit deletion or due to  
compaction) should first be renamed or moved to special trash dir just  
before being actually deleted. The file should be given a random name  
to avoid conflicting with previous deletions.

In case you die after the rename but before the deletion, on startup  
CouchDB would need to scan and delete all the files in the trash  
directory.

If you think that will work I can implement it on a branch for testing.

-Damien


Mime
View raw message