[cvsnt] Re: Major problems with CVSNT 2.0.58d

Hartmut Honisch Hartmut_Honisch at web.de
Wed Dec 22 13:53:05 GMT 2004

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.

> > I see - so it's a bug in 2.0.58d that is CVSNT modifies the ACLs of
> > repository files on the server because of CYGWIN being set to ntsec?
> More an oversight...  The server doesn't really need ntsec - it can use
> ntea as the user never sees the temporary files.

Just to clarify this: I'm not talking about temp files, I'm talking about
CVSNT modifying the ACLs of "...,v" files in the repository, thereby causing
server-side "permission denied" errors for subsequent commits by other
users, which I'd really not just call an "oversight".

> > It happened to me (and various other users). In my case, I was told to
> > CYGWIN=ntsec when installing sshd on Cygwin. I had no idea that it would
> > affect CVSNT (which I hadn't even installed when I set up sshd).
> That's odd advice.

I know that now, but didn't then

> It isn't a problem though unless you've done some pretty odd things to
> the file permissions (I wasn't able to replicate the problem even trying
> very hard), and also set CYGWIN (which isn't the default).

I can easily reproduce the "permission denied" bug with 2.0.58d (it's gone
in 2.0.62 though, so the next stable will fix it anyway). I don't know
whether you want to release a 2.0.58e to fix it - depends on how soon you're
going to release the next 2.0.6x stable.

If you want to reproduce it with 2.0.58d, I'd be glad to help. It all
happens on the server side - client side isn't an issue.

> > Why do you want other users to fall into that trap as well? If you want
> What trap?

The trap of having CYGWIN=ntsec set on the server (because of that
odd-adviced sshd installation), thereby causing CVSNT to corrupt my
repository file permissions.

> For the permissions to be effective/useful CVSNT and CYGWIN should be
> synchronised.  If they're different it doesn't really work.  The whole
> point of using a compatible scheme is that they interoperate.

I see.
But if the CYGWIN variable isn't set (as it usually is), Cygwin defaults to
ntsec, and CVSNT defaults to ntea, so the schemes are not synchronized 99%
of the time.
The user has to change *something* to synchronize Cygwin and CVSNT anyway.
And personally, I find it very confusing to set the variable CYGWIN=ntsec,
because being called "CYGWIN", I'd expect it to affect Cygwin (which it
doesn't as it defaults to ntsec anyway) and not CVSNT (which it actually

It seems that CVSNT and Cygwin using different ways to store rwx-attributes
works for 99% of all users - and for the remaining 1% (which are still quite
a few), it would be much more transparent what's actually happening if the
CYGWIN variable only affected Cygwin applications and not other Windows apps
such as CVSNT. I understand your hesitation to officially introduce yet
another environment variable, but IMO that's definitely where this
ntsec/ntea switch belongs.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook