This is probably fixable, but rather than get lost in the 'cvs edit' code, I though I'd post it here... Has anyone seen this before and fixed it? Tony -------- Original Message -------- Subject: CVSNT: Notes on case sensitivity problems in NT Date: Tue, 9 May 2000 13:21:16 -0700 From: Tad Hetke <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Tony, I am doing some research on CVS and came upon an interesting case sensitivity issue that has not been addressed as of the 1.10.8 release. Since I have no compiler as yet (ordered...but not waiting for it), I thought I would send you the description on the off chance that you may have found and addressed this already. If you do these steps, the problem should become clear. cvs add junk cvs commit junk cvs edit junk cvs edit Junk At this point, if you look in $CVSROOT/CVS/fileattr, you will see that two attribute records have been added for the file "junk". One with an upper case 'J'. Upon commit, only one is removed. This makes problems with respect to any scripts that may rely on the contents of fileattr. Here is what I believe is happening. Somehow, cvs is accepting the case insensitive filename and passing it to the routines in edit.c as whatever the string is on the command line. This seems to be a problem in the fn* routines that handle sensitivity. Here is what I think should be done. It seems to me that when cvs discovers that a file is being accessed, it should simply use the name from the file itself, not the string passed in by the user. This will work beautifully on systems like NT where case is preserved, but not enforced. This will allow cvs internals to use the file in a case sensitive manner (as it does already), while removing the requirement that the user get the right case on the edit command. There may be other commands that have this problem, so I think modification of the command itself could be inappropriate. Tad Hetke Senior RTOS Engineer Oresis Communications (503) 466-6318
