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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 30 02:29:11 2005