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 01:17:22 UTC
Windows 'Access Denied' errors was: Re: svn.collab.net is now running
Subversion 0.23.
Branko Čibej wrote:
> Nonsense. Any system component may touch the files I create only in a
> way that doesn't interfere with normal file handling semantics. I submit
> that any filter drivers that are fiddling with those files are broken if
> my user-mod app can detect them (via an access-denied status on move,
> for example).
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...
Anyway, immediately after getting a failure I can go look at the files
-- the destination file is not read-only and I have full permissions on
both. AND a simple retry works.
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 was: Re: svn.collab.net is now
running Subversion 0.23.
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> Branko Čibej wrote:
>
>> Nonsense. Any system component may touch the files I create only in a
>> way that doesn't interfere with normal file handling semantics. I submit
>> that any filter drivers that are fiddling with those files are broken if
>> my user-mod app can detect them (via an access-denied status on move,
>> for example).
>
>
> 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...
Filter drivers can screw with anything they like. A very powerful tool
-- full protective clothing required, and your life insurance doesn't
cover it. :-)
> Anyway, immediately after getting a failure I can go look at the files
> -- the destination file is not read-only and I have full permissions
> on both. AND a simple retry works.
Exactly. That means there's a reace somewhere. Whether we can uncover it
using a simple testcase remains to be seen...
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
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
Re: Windows 'Access Denied' errors
Posted by "D.J. Heap" <dj...@shadyvale.net>.
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 was: Re: svn.collab.net is
now running Subversion 0.23.
Posted by Jack Repenning <jr...@collab.net>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org