Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
--- Tony Hoyle wrote:
> Peter Crowther wrote:
> >>From: rrankin1424-cvsnt at yahoo.com
> >>Well, I guess one can never be 100% certain. However, other
> >>than A/V software,
> >>I can't imagine what could be holding any of the files open.
> >>I'll run some
> >>tests again with the A/V software disabled, but I'm not hopeful.
> >
OK. I've temporarily disabled the A/V software, reinstalled 58c, and I'm still
having the rename problem. It seems that I am able to successfully commit a
file once with 58c, but after that I get the rename problem. When I go to the
security tab on the file properties dialog for the file in the repository on
the server (i.e., not in my local sandbox), I get the following popup dialog as
soon as I click the Security tab:
The permissions on <file>,v are ordered incorrectly, which may cause some
entries to be ineffective. Press OK to continue and sort the permissions
correctly, or Cancel to reset the permissions.
I've also noticed that the files in the repository that are causing the problem
have the read-only bit set. If I clear the read-only bit, I can commit the file
again; however, as soon as it's been committed, the read-only bit is set again,
and I can no longer perform a commit operation on the file.
If I drop back to 58a, the state of the read-only bit doesn't seem to make any
difference. I can commit the file regardless of its state. Is it possible that
58a used to clear the read-only bit, do its business, then restore it if it was
previously set while 58{b,c} is missing a step in there somewhere?
Rick