Re: Subversion Permission denied moving .svn/tmp/entries to .svn/entries

Branko Čibej <[email protected]> Tue, 30 Aug 2005 02:26:53 +0200
Newsgroups gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user
Message-ID <[email protected]>
Ben Collins-Sussman wrote:

>
> On Aug 29, 2005, at 8:59 AM, GOVAERTS Lieven wrote:
>
>>
>> svn: Can't move
>> '/cygdrive/c/xxxx/trunk/oracle/packages/.svn/tmp/entries' to
>> '/cygdrive/c/xxxx/trunk/oracle/packages/.svn/entries': Permission  
>> denied
>>
>> Does anybody have an idea what can cause this type of problem? Is  there
>> a workaround available?
>
>
> The svn client tends to create temporary files, then quickly 'move'  
> them into proper place.  It's a way of manipulating the working copy  
> in an atomic way.
>
> These sort of errors are almost always the result of some other  
> process holding the file-handle open immediately after the tmpfile is  
> created.  On Windows, you're not allowed to move a file if another  
> process has it open... so the move fails.  (On unix, this is not the  
> case.)
>
> The usual culprits are virus scanner software or disk indexing  
> software (like google desktop).
>
In this case the reason is probably far simpler. The .svn/entries file 
is read-only. It should be deleted as part of the move; but, unlike on 
Unix, you can't delete a read-only file on Windows. The Windows build 
takes care of that by making rename targets writable first. The Cygwin 
build probably thinks it's a Unix port, so it skips that part. So 
obviously, whoever is responsible for the Cygwin package has to fix 
this. It probably involves replacing a few instances of

    #ifdef WIN32

with

    #if defined(WIN32) || defined(CYGWIN)

I see candidates in svn_io_file_delete, svn_io_file_rename, 
svn_io_write_version_file. There are probably others.

I wonder if the Cygwin packager runs our regression tests. I can't 
imagine how this wouldn't show up there. I'm also wondering what 
Cygwin's APR does about setting the read-only bit; it's possible that it 
uses the unix algorithm which changes file permissions, not the 
attributes. If that's the case, then working copies created by the 
Cygwin svn port are different than (incompatible with!) the ones created 
by the regular Windows Subversion clients.

-- Brane