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 13:03:39 -0400 Lines: 93 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: X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Ronald Landheer-Cieslak wrote: > 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.. Actually, upon some more investigation it looks like the problem is not in isfile(), but in the fact that isfile() is even called: it is only called for this "potentially conflicting" file.. I guess I'm scratching ;) 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/