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