Mail Archives: cygwin/2004/07/22/13:03:50
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/
- Raw text -