Slight problem with case sensitivity on managed mounts with CVS-1.11.6

[Ronald Landheer-Cieslak]

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/