You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "D.J. Heap" <dj...@shadyvale.net> on 2003/05/23 15:45:43 UTC

Re: Windows 'Access Denied' errors

Jack Repenning wrote:
> At 7:17 PM -0600 5/22/03, D.J. Heap wrote:
> 
>> Yes, this is the one big clue (it seems to me) that NTFS may be at 
>> fault...access denied is the return code, not sharing violation.  I 
>> can only make access denied errors occur if the destination file is 
>> read-only or if I don't have permissions to one of the files. Sharing 
>> violation is the normal return code for 'something else is dorking 
>> with the file' type situations.  Perhaps filter drivers can screw with 
>> that, though, I don't know...
> 
> 
> I think you can get "access denied" if someone else is dorking with 
> _the_directory_ that contains the file.
> 
> "dir" in the cases I'm thinking of shows "Illegal access" (and no 
> directory contents), or something close to that.

Hmm, do you mean like adding/removing files in the same dir or 
moving/deleting the directory?

I've had a single stress.pl running on two machines all night long (up 
to revisions 7200 and 5400) and no troubles so far.

However, on my work machine (dual processor -- well hyperthreaded -- 
with Sophos) it died with access denied at revision 1204.  But after 
more investigation it was because I had not completely disabled AV -- so 
it starts a nightly scan of the whole machine and looking at the AV 
logs, stress.pl died at about the time the AV scan reached those 
directories.  And now I'm suspecting that is what caused my other 
'access denied' failures...I've never had them during the day (with AV 
off).  Argh.

Of course, that doesn't explain Brane's failure...but I'm to the point 
now where I think all my failures can be laid at AV scanning's door.  I 
will start up multiple stresses tomorrow if I have no more failures 
today or tonight with AV *uninstalled*.  I wish I could leave it that 
way permanently.

DJ


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Windows 'Access Denied' errors

Posted by Jack Repenning <jr...@collab.net>.
At 9:45 AM -0600 5/23/03, D.J. Heap wrote:
>Jack Repenning wrote:
>>I think you can get "access denied" if someone else is dorking with 
>>_the_directory_ that contains the file.
>
>Hmm, do you mean like adding/removing files in the same dir or 
>moving/deleting the directory?

Well, I'm not exactly sure *what* I mean; it's a hazy memory.  As 
best I recall, it went like this:

We had a distributed service that involved files (something called 
"ClearCase"; perhaps you've heard of it?).  We had some files stored 
on a Windows (VOB) server (WinNT 4.0sp6, I'm pretty sure).  We had 
both Windows and Unix clients of these files (don't ask, I just don't 
want to go there).  We had a Windows NFS-server product installed to 
make that happen.  Occasionally,  things would lock up.  Eventually 
(with the help of the NFS product vendor) we discovered that the NFS 
server would "lock" the directories in some sense, and at times 
neglect to lift the lock.  We were never, so far as I can recall, 
clear even on what user operation led to the problem, let alone what 
code the server was executing (and failing to un-execute).  We had a 
tool from the NFS vendor that would relinquish these locks, which we 
ended up running every five minutes or something like that.  But I 
might be wrong about nearly any detail in that list.

But I do recall that the precise symptom depended on the interface 
you used to test it.  The most reliable test was to open a cmd.exe 
window, on the server, and "dir" around until you found a directory 
with owner shown as "Unavailable".  Other symptoms included several 
different errors, including (I think) "Access Denied" and "Illegal 
Access."


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org