Mail Archives: cygwin/2002/05/18/14:06:08
Lapo Luchini wrote:
> I added Cc to Charles Wilson, CygWin's CVS package mantainer, sorry if
> I quote everything, but it's for him getting a sense out of the message ^_^
>
> Introduction: I filed a bug on TortoiceCVS "feature reqeust" tracker to
> improve support of cygwin's CVS bty TortoiseCVS (that IMHO is the best
> CVS front-end around), they told me that cygwin's cvs has some problems
> about daylight saving time (that are indeed bug of windows itself, it
> seems)
> https://sourceforge.net/tracker/index.php?func=detail&aid=551482&group_id=48103&atid=451975
The above is a bad link. Browsing thru the buglist for tortoisecvs, I find:
[ 556160 ] timezone problem FAT vs NTFS
http://sourceforge.net/tracker/index.php?func=detail&aid=556160&group_id=48103&atid=451972
which is blamed on CVSNT, not windows itself.
Do you have a specific example using cygwin's cvs via the command line,
where Daylight Savings Time causes a timestamp problem?
>>>> [lapo] But cygwin's mantainers are not usually that conservative,
>>>> they welcome patches... if you already have a patch to solve that
>>>> problem could you please send it to cygwin's CVS mantainer?
Yes I AM conservative when it comes to cvs. It would be very bad if it
got broken, as that would halt every developer who hacks on cygwin1.dll
or other cygwin packages from within a cygwin environment. (Folks who
develop using a cross-build environment for cygwin on linux would be
"safe", but) Worse, bad check-ins could seriously scrog the cygwin,
gcc, binutils, and cgywin-apps repositories on sources.redhat.com.
I am considering an update to cvs-1.11.2 in the (relatively) near future
-- but that package will have about a two month shakedown period as a
'test' package before it gets made current...
>>> [torsten] No, we do not maintain CVS. We just use the CVSNT port.
>>>
>>
>> [francis] Well, the biggest thing the cygwin CVS maintainer could do
>> is to
>> actually ship CVSNT. CVSNT has been backported to Unix, and many people
>> use it as a server under Unix. This port would be fiddly, as they would
>> want to use the Unix port of CVSNT with cygwins compatibility layer, but
>> still maintain features like the timestamp stuff on different filing
>> systems. Euch.
>>
>> I guess cygwin could "fix" their stat function under Windows to look at
>> the filesystem type, like CVSNT does. This could cause all sorts of
>> weird consequences in other programs though.
I still don't see a description of WHAT is wrong. "maintain features
like the timestamp stuff". "fix the stat function to look at the
filesystem type". ***what is broken???*** cygwin-cvs works fine for me
and hundreds of others...
From CVSNT Changelog:
31/10/01: Added equivalent DST fix for utime function (fixes
edit/unedit). Removed WinCVS 1.2 DLL.
22/05/01: Merge in the latest version of stat() fixes by jmg. This
should cover about 99% of cases now. An equivalent fix will (hopefully)
be in the next version of WinCVS
26/03/01: Lots of DST fun... This is not a bug in cvsnt, nor is it as I
initially thought a bug in WinCVS (although it handles it in a different
way). It's an NT4/Win2k bug (test: Create a file, write down the time it
was created, change your calendar to December. Check the time on the
file. Surprised? so was I...). The quick workaround is to do 'cvs status
-q' from the root of your sandbox which will touch all the files again.
From
http://www.devguy.com/fp/cfgmgmt/cvs/#DST
-------------
3) Why does this problem exist?
Because Microsoft's Win32 API file status reporting functions report
incorrect file modification dates. According to Microsoft, "This is by
design." Thus, file status functions that work properly under Unix
return incorrect results under Windows. Moreover, the incorrect results
are incorrect in different ways depending on whether the file system is
FAT or NTFS. WinCVS and cvsnt correct for this problem on FAT file
systems, but the original authors did not correctly allow for the
differences under NTFS.
Microsoft's faulty documentation is more to blame than the hardworking
authors of WinCvs and cvsnt.
---------------
Now, it becomes more clear...there have been several instances where the
time computation functions in cygwin -- which are in the times.cc and
localtime.cc files -- were modified to compensate for these sorts of
problems. cygwin's stat() function for disk files (in
fhandler_disk_file.cc) uses cygwin's own time routines to convert the
time values as returned by the windows routines into the the time values
that go into the stat structure. As it happens, the function used to do
this is to_time_t, which converts the windows-time (# of 100 nanoseconds
since Jan 1 1601) to the unix time (# of seconds since Jan 1 1970).
My point: cygwin itself seems to handle timestamps properly now.
Whatever needs fixin' was fixed long ago, AFAICT. In fact, if you do
the test mentioned above (26/03/01: ...) from within a bash shell, and
use 'ls -l --full-time' you do NOT see the "jumping timestamp" problem.
You do see it if you follow that procedure from a cmd.exe prompt, and
use 'dir' to list the files.
So, AGAIN I say, **what is the problem**? Do you have a testcase
demonstrating a problem using cygwin's cvs client via the command line?
Or have you only seen this bug when using TortoiseCVS -- which doesn't
like cygwin-cvs anyway?
>> In short, I don't have a patch which is in a form that th cygwin CVS
>> maintainer could use. Somebody would have to sit down and thinkin about
>> these issues to make one. Can such a patch apply to main CVS? Is it
>> worth doing that, rather than using CVSNT? If changing to CVSNT what
>> other issues are there?
>>
I have no intention of switching over to CVSNT. As far as I am
concernedc, that is a totally different package. So far, you haven't
even presented me with evidence that there's anything wrong with the
current cygwin cvs.exe's handling of timestamps.
> I've seen CVSNT has 6Mb of diff from CVS... quite hard to extract only
> that part...
>
>>>>> [torsten] Do you have any special reason to prefer Cygwin's cvs.exe
>>>>> for the CVSNT one?
>>>>>
>>>>>
>>>>
>>>> [lapo] Just that I use cygwin to develop and I compile from cygwin
>>>> the programs I store in my CVS repository (or on sourceforge)...
>>>> mixing CVSs gives strange permission on files and mixed EOL (13-10
>>>> versus 10)...
[rest snipped]
Lapo, you wondered why I had not responded to this message. It's because
it was totally unclear as to WHAT the problem was. It wasn't clear
whether you were actually reporting a bug with cgywin's cvs or just
letting me know that TortoiseCVS doesn't work well with cygwin cvs (and
that's my problem because???). Or maybe you were slyly advocating that
I drop "regular" cvs and use cvsnt. I dunno. I couldn't tell -- and
I've got better things to do that try to figure it out. Give me a test
case with MY cvs. Tell me what is wrong and what should be fixed.
Better, give me a patch. But don't expect me to respond to a cc: of a
tangential discussion that only vaguely involves my cvs package.
I DO read every message that concerns cvs. I don't always respond --
sometimes because the message makes no sense (like yours - sorry, but
it's the truth) and sometimes just because I don't have time to deal
with the issue. But they all get filed in the cygwin-cvs/ folder, and I
always review them before making a new release.
('course, it's been so long since I made a new release of cvs, that the
cygwin-cvs/ folder has a pretty huge stack of messages in it...)
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -