Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com From: Ronald Landheer-Cieslak Subject: Re: Slight problem with case sensitivity on managed mounts with CVS-1.11.6 Date: Thu, 22 Jul 2004 11:48:56 -0400 Lines: 82 Message-ID: References: <20040722143326 DOT GB3457 AT trixie DOT casa DOT cgf DOT cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet AT sea DOT gmane DOT org X-Gmane-NNTP-Posting-Host: dslcom1-156.express.oricom.ca User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 In-Reply-To: <20040722143326.GB3457@trixie.casa.cgf.cx> X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Christopher Faylor wrote: > On Thu, Jul 22, 2004 at 10:27:38AM -0400, Ronald Landheer-Cieslak wrote: > >>Hello CVS maintainer (et al.), >> >>I've got a slight problem with CVS when running it on a directory >>mounted in managed mode: the directory being case-sensitive, ``cvs >>update'' should *IMHO* not warn about a file whose name might clash >>with another due to its case (and on ``cvs checkout'', it doesn't). >> >>The file in question is called Hash.h, which has a little brother >>called hash.h. >> >>The error is emitted on line 1809 of src/client.c, which also contains >>a lengthy comment on why the error may be emitted, confirming my >>hypothesis. >> >>My question is not: "please fix this.." - my question is whether you'd >>be interested in a fix. The fix would consist of >>* checking whether the file being updated is on a managed mount (don't >> know how to do that yet, but I assume it's possible) >>+ if so, assume case-sensitivity >>- if not, assume case-insensitivity > Why not send the comment and your hypothesis here rather than informing > everyone that there is a comment and asking if anyone would be > interested in a fix? I don't think many people would be interested in > downloading the sources for cvs to see what you're talking about. From > your description it is difficult to tell if your problem is with cygwin > managed mounts or with cvs. OK, the problem is with CVS - the managed mounts are working properly. CVS assumes Cygwin is/runs on a case-insensitive (file)system, which is usually the case. On managed mounts, however, the assumption fails, and CVS complains about conflicts in file names that do not exist. (I thought this was clear from the original post, but apparently, that was not the case..) The comment says this: /* This error might be confusing; it isn't really clear to the user what to do about it. Keep in mind that it has several causes: (1) something/someone creates the file during the time that CVS is running, (2) the repository has two files whose names clash for the client because of case-insensitivity or similar causes, See 3 for additional notes. (3) a special case of this is that a file gets renamed for example from a.c to A.C. A "cvs update" on a case-insensitive client will get this error. In this case and in case 2, the filename (short_pathname) printed in the error message will likely _not_ have the same case as seen by the user in a directory listing. (4) the client has a file which the server doesn't know about (e.g. "? foo" file), and that name clashes with a file the server does know about, (5) classify.c will print the same message for other reasons. I hope the above paragraph makes it clear that making this clearer is not a one-line fix. */ A wee bit further digging brings us to the isfile() function, of which diverse versions exist in the code. The solution would seem to be to * either write a Cygwin-specific one or * choose the right one to use >>The patch would probably be Cygwin-specific, so I doubt it would be >>possible to get it up-stream, but I'll try to make it as clean as >>possible.. > That seems to imply that the problem is with cvs since any fix to > cygwin would be cygwin-specific. If that is the case, then any fix > should probably go upstream. Yes, the problem is with CVS, not with Cygwin. Personally, I though the first paragraph of the original post made that clear - apparently, it didn't, so I apologize. Also, the post was primarily intended for the CVS maintainer, whom I assumed has the source already and could trivially look up the file src/client.c. That being said, the comment in question is of no importance to my question: my question being "I found an itch in CVS: this is the itch, would you like me to scratch it?" the details of the scratching would only be interesting if there were any interest in the scratching itself were interesting.. rlc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/