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 set > > 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 ntea > > 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 does). 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. -Hartmut