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.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Bo Berglund > Sent: Wednesday, 08 February, 2006 13:17 > > On Wed, 8 Feb 2006 09:49:26 -0800, "Michael Wojcik" > <Michael.Wojcik at microfocus.com> wrote: > > >> From: cvsnt-bounces at cvsnt.org > >> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Bo Berglund > >> Sent: Wednesday, 08 February, 2006 11:56 > >> > >> > >> To quote the error message: > >> > >> cannot change permissions on temporary directory > >> D:\CVSTEMP/cvs-serv2612 > >> > >> Why does this happen? > > > >When this message is produced, CVS has successfully created the > >directory, but CVS_CHMOD has failed. (It'd be nice if CVS reported the > >system error code, so we'd know *why* it failed.) > > Actually, the directory is *not* created. I had a look at the temp > folder while running these commands. Unless of course cvs first > succeded to create the dir, then failed changing permissions and then > finally vcleaned up by removin the dir again. This would not be slow > enough to show up in Windows Explorer. That's certainly possible, but it's made me think of another possibility: the directory creation failed, but CVS failed to detect the error, and then _tchmod failed with ENOENT. (Also, I should note again that I'm not looking at the 2.5 sources; I have 2.0.51d on this machine at the moment. Something may have changed in server.cpp.) CVS determines that directory creation has succeeded when mkdir_p returns 0. mkdir_p actually returns errno if a call to CVS_MKDIR fails; if somehow CVS_MKDIR can fail but set errno to 0, CVS will incorrectly decide that mkdir_p succeeded. CVS_MKDIR on Windows is actually wnt_mkdir (in windows-NT/mkdir.cpp). wnt_mkdir calls CDirectoryAccess::mkdir (I don't know why it doesn't just use _tmkdir), and then calls _dosmaperr(GetLastError()) to set errno if that fails. _dosmaperr should set errno to EFAULT for unrecognized errors, and to the value of the "dos" member of the appropriate entry in the "errors" array if it finds the system error code there. Those are all valid non-zero errno values, so it doesn't appear that _dosmaperr should leave a 0 in errno. CDirectoryAccess::mkdir appears to return false (indicating failure and triggering the call to _dosmaperr) if CreateDirectory fails. CreateDirectory is a Win32 API call. It's possible that it's failing but reporting success, but that seems unlikely. The call to CreateDirectory does also transcode the directory name (via CFileAccess::Win32Wide), so it's possible that something's going wrong there, and the directory's being created with the wrong name, but again that seems unlikely. On the other hand, since you only now started having this problem, it may be something has changed in all of this since 2.5 which is now masking the failure. > I looked up the security settings for the CVSTEMP folder and went over > the Advanced page for every single entity listed to have permissions > here. THey had all the checkboxes for allow checked and none for deny > checked... What you really want to check is the "Effective Permissions" tab. ACLs are very complicated, what with users and groups, multiple group membership, deny and allow rules, and inheritance. And this sort of operation is additionally complicated by the fact that an object is being created and modified: the ACL for the parent object (plus any inherited from ancestors) control the creation process; then changing the object will be governed by the ACL of the new object plus any inherited from ancestors. > >I'd double-check what account the CVS server is using, then look at > >effective permissions for the D:\CVSTEMP directory for that user. > > I also did the following: > We have two CVS user groups in the domain, CVS_Admins (where I am the > only member) and CVS_Users (where all of my developers are members). > So we added the cvs_setup domain user account to CVS_Users group and > hoped that this would fix the problem. > But not, the same error for pserver users aliased to cvs_setup. > > Then I even went as far as rebooting the CVSNT Win2000 Server PC in > order for it to refresh the security tokens from the domain > controller. But no-go, same error again after startup. > > Finally as a check I again added the domain\cvs_setup account to the > local Administrator group. This again made the pserver operations work > properly! But I *really* do not want to be forced to have the pserver > users operate as a server admin!!!! Understandable. Well, it looks like you've confirmed that the CVS server is operating under the domain\cvs_setup account, anyway. That's useful. When you checked the permissions for D:\CVSTEMP, did you use the Effective Permissions tab (Security -> Advanced -> Effective Permissions -> Select and enter "domain\cvs_setup") to verify that you were looking at the results for that user account, including all inherited permissions? If that looks OK, then I'd try the following: - Use runas to start a command prompt as the domain\cvs_setup user. (You may have to temporarily enable login for that user, etc.) - cd to d:\cvstemp and create a directory with md. - If that succeeds, take a look at the effective permissions on the new directory - it may be that you're losing some permissions on new objects because something's not inheritable. - If they look OK, try setting the read-only flag with attrib +r. That's not exactly what CVS is doing, but it should fall under the same rules, since _tchmod only sets or clears the file's read-only attribute flag. If all of that doesn't work, I'll try taking a look at the 2.5 sources tomorrow, if I have time, to see if something's different there. (It just occurred to me, for example, that maybe in 2.5 the other calls that wnt_chmod makes might affect its return code, unlike in 2.0.) -- Michael Wojcik Software Systems Developer, Comms phone 517 676-0892 Micro Focus mobile 517 862-9464 Mason, Michigan