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
Received on Fri May 23 17:46:47 2003