On Thu, 2004-04-22 at 03:57, solo turn wrote:
> if it happens, it happens for ALL the .svn in the deleted directory, one each time.
>
> i'll try two things:
> - copy it on the same disk and remove the whole working copy with cygwin
> - copy it (in this state) on another box and try the up there
>
> i'm not too good in windows programming, but i think you should be able to print the permissions
> of that directory. something like "if access denied then print permissions, print permissions of
> directory where this thing is in, ...".
>
> or could you set the loop longer/more often, as philipp suggested? why not doing a "rm -rf" on the
> whole subdirectory? or throw this permission setting away? a working copy is anyway personal. if i
> want to write over it i can, and if i do not, i do not have to.
>
> do you know the cygwin-code? what is different in this code? i just know that it works on this
> machine with the same directory.
>
We don't mess with permissions at all on Win32-- unless some outside
application has done something to your working copy, or you are using a
different user than the one that created the working copy, there cannot
be any permissions problem. Since you can 'rm -rf' it this is probably
not the case anyway -- obviously you do have delete permissions.
We are doing a 'rm -rf' programmatically. cygwin must eventually be
calling the Win32 delete API which is just what we do through APR
eventually.
I've only seen two situations where 'access denied' is returned from a
call to delete a directory -- you really don't have permission
(obviously not the case since you can 'rm -rf' it from a shell), and
when some application is holding on to the directory or a file in the
directory.
It could be that some unusual sequence of 'update' events causes
Subversion itself to leak a temp file or something which could easily
later cause the removal of directories to fail -- I think this is likely
what is happening, since there seems to be no other explanation. And, I
think, this would not bother unix clients as they don't lock
directories/files like Windows does.
In order to track it down, though, we need a repro recipe of what
'updates' were occurring to get into this situation. You seem to have
it happen fairly often, so could you try to do that, please? A recipe
of changes to the repository that causes a client to croak on an
update? You seem to have updates that delete directories a lot, which I
think may be unusual -- at least, I know I do not delete whole
directories from the repository very often.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 22 16:09:06 2004