From: Keith M. <kei...@us...> - 2007-11-23 18:03:02
|
Hi All, I thought we might discuss this here, before I file a formal bug report. This is looking like something of a show stopper, and I'd particularly like to see responses from Chuck and/or Cesar, but if anyone else would like to join in, please do so. I've installed Chuck's most recent cvs-1.11.22-MSYS-1.0.11.tar.bz2, and I've had no end of headaches since. The setup is as follows:-- - I have a Win2K-Server network share, hosted by a machine on the in-house LAN, and mapped as drive j: on my Win2K workstation. - On that share, I have a CVS repository at j:/technotes/cvs - I have an MSYS mount table entry for /technotes -> j:/technotes - Within the CVS repository, I have a module called `general'. Now, I wanted a fresh check out of the `general' module, so I did:-- $ cvs -d /technotes/cvs co general cvs checkout: in directory general: cvs [checkout aborted]: there is no version here; run 'cvs checkout' first Well, duh? What the heck does cvs think I'm trying to do here, if not precisely what it's telling me I must do? Substituting `checkout' for `co' doesn't help either -- I get exactly the same response, just as I would expect. FWIW, at this point I have the directory structure for the general working copy established, with CVS/Repository and CVS/Root written, CVS/Entries created but empty, and no other files at all. Ok, I'm getting desperate now. Fire up Cygwin, with cvs-1.11.17, cd to make the Cygwin working directory match the MSYS location, and:-- $ cvs -d /cygdrive/j/technotes/cvs co general cvs checkout: Updating general U general/anin-man.ms U general/today.ms Now, I've got a checked out working copy, so back in MSYS:-- $ cd general $ mv ../pv-dual.ms . $ gvim ChangeLog [create a ChangeLog for the general module] $ echo /technotes/cvs > CVS/Root $ cvs add ChangeLog pv-dual.ms cvs add: scheduling file `ChangeLog' for addition cvs add: scheduling file `pv-dual.ms' for addition cvs add: use 'cvs commit' to add these files permanently $ cvs ci cvs commit: Examining . [...] At this point, I've lost the scroll-back buffer, because vi has trashed it, but here cvs tries to invoke emacs, which I neither have nor wish to use, to edit the log message, so I aborted that commit, and tried:-- $ EDITOR=vi cvs ci cvs commit: Examining . [runs `vi' to let me specify the log message] RCS file: /technotes/cvs/general/ChangeLog,v done Checking in ChangeLog; /technotes/cvs/general/ChangeLog,v <-- ChangeLog initial revision: 1.1 done RCS file: /technotes/cvs/general/pv-dual.ms,v done cvs commit: cannot lstat file pv-dual.ms: No such file or directory So, here's major headache #2: on any multiple file commit, only the first file listed, either explicitly or implicitly, is successfully committed; the commit has to be repeated as many times as there are files pending, to commit them all. (For an implicit files list, the same command repeated sufficient times will commit each in turn). Also, for a multiple file commit which modifies existing repository files, rather than adding new files, the failure condition, and hence the diagnostic report, is not quite the same:-- $ cvs -qn up M ChangeLog M pv-dual.ms $ EDITOR=vi cvs ci cvs commit: Examining . [runs `vi' to let me specify the log message] Checking in ChangeLog; /technotes/cvs/general/ChangeLog,v <-- ChangeLog new revision: 1.2; previous revision: 1.1 done Checking in pv-dual.ms; /technotes/cvs/general/pv-dual.ms,v <-- pv-dual.ms cvs [commit aborted]: can't stat file pv-dual.ms: No such file or directory Can you investigate this please. Regards, Keith. |
From: Cesar S. <ces...@gm...> - 2007-11-25 22:21:33
|
Keith Marshall wrote: [snip] > I've installed Chuck's most recent cvs-1.11.22-MSYS-1.0.11.tar.bz2, and > I've had no end of headaches since. The setup is as follows:-- > > - I have a Win2K-Server network share, hosted by a machine on the > in-house LAN, and mapped as drive j: on my Win2K workstation. > [snip] I would like to rule out the possibility of a corrupted repository. Could you try again, but with a newly created repository? I tried to duplicate your setup by creating a CVS repository on a LAN share. I didn't have any trouble on checkout, but I did get an error while committing (but not the same error as yours). Here is my test log: 1) I created a share on an old Windows 95 box, full permissions, no password. 2) I mapped it to the T: drive of my PC, which has Windows XP Home Edition. 3) I created a mapping of t:/work to /work on /etc/fstab 4) Then: $ cvs -d /work/cvs init $ mkdir foo && cd foo $ echo 10 > a.txt $ echo 20 > b.txt $ echo 30 > c.txt $ cvs -d /work/cvs import -m "Initial import" foo foo start N foo/a.txt N foo/b.txt N foo/c.txt No conflicts created by this import $ cd .. $ rm -r foo $ cvs -d /work/cvs co foo cvs checkout: Updating foo U foo/a.txt U foo/b.txt U foo/c.txt $ cd foo $ echo 40 >> a.txt $ echo 50 >> b.txt $ cvs -qn up M a.txt M b.txt $ cvs ci cvs commit: Examining . Checking in a.txt; /work/cvs/foo/a.txt,v <-- a.txt new revision: 1.2; previous revision: 1.1 cvs [commit aborted]: cannot rename file /work/cvs/foo/,a.txt, to /work/cvs/foo/a.txt,v: Permission denied Repeating these steps on a local drive does not show this problem. Regards, Cesar |
From: Keith M. <kei...@us...> - 2007-11-25 23:23:03
|
Hi Cesar, Thanks for following up on this. On Sun, 2007-11-25 at 20:21 -0200, Cesar Strauss wrote: > Keith Marshall wrote: > [snip] > > I've installed Chuck's most recent cvs-1.11.22-MSYS-1.0.11.tar.bz2, > > and I've had no end of headaches since. The setup is as follows:-- > > > > - I have a Win2K-Server network share, hosted by a machine on the > > in-house LAN, and mapped as drive j: on my Win2K workstation. > > > [snip] > > I would like to rule out the possibility of a corrupted repository. > Could you try again, but with a newly created repository? I should have mentioned it, but I did try this -- completely fresh repository, albeit on the same share. Maybe I should try again, on a different host, or at least with a different share. > I tried to duplicate your setup by creating a CVS repository on a LAN > share. I didn't have any trouble on checkout, but I did get an error > while committing (but not the same error as yours). > > Here is my test log: > > 1) I created a share on an old Windows 95 box, full permissions, no > password. Hmm. IIRC, I have R/W permission, but not full control; I can't confirm that right now, but will check it tomorrow. Access to the share is via the Win2K domain authentication, and I do have to supply a password for login to the domain. When I created the new repository, there was no problem reported at all with `cvs init', or subsequently with `cvs import', but exactly the same failure, on a subsequent `cvs checkout'. `ls -aR' on the repository confirmed that all expected files were present, and they appeared to be correctly formed, in all respects; Cygwin's CVS client could again check them out successfully. It is disturbing that you cannot reproduce this; where do we go from here? Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-11-26 13:03:17
|
Quoting Keith Marshall <kei...@us...>: > Hi Cesar, > > Thanks for following up on this. > > On Sun, 2007-11-25 at 20:21 -0200, Cesar Strauss wrote: >> Keith Marshall wrote: >> [snip] >> > I've installed Chuck's most recent cvs-1.11.22-MSYS-1.0.11.tar.bz2, >> > and I've had no end of headaches since. The setup is as follows:-- >> > >> > - I have a Win2K-Server network share, hosted by a machine on the >> > in-house LAN, and mapped as drive j: on my Win2K workstation. >> > >> [snip] >> >> I would like to rule out the possibility of a corrupted repository. >> Could you try again, but with a newly created repository? > > I should have mentioned it, but I did try this -- completely fresh > repository, albeit on the same share. Maybe I should try again, on a > different host, or at least with a different share. > >> I tried to duplicate your setup by creating a CVS repository on a LAN >> share. I didn't have any trouble on checkout, but I did get an error >> while committing (but not the same error as yours). >> >> Here is my test log: >> >> 1) I created a share on an old Windows 95 box, full permissions, no >> password. > > Hmm. IIRC, I have R/W permission, but not full control; I can't confirm > that right now, but will check it tomorrow. Access to the share is via > the Win2K domain authentication, and I do have to supply a password for > login to the domain. > What type of file system is the share? I can see this being an issue if /somedir/cvs reports /SOMEDIR/CVS instead with the stat function. > When I created the new repository, there was no problem reported at all > with `cvs init', or subsequently with `cvs import', but exactly the same > failure, on a subsequent `cvs checkout'. `ls -aR' on the repository > confirmed that all expected files were present, and they appeared to be > correctly formed, in all respects; Cygwin's CVS client could again check > them out successfully. > > It is disturbing that you cannot reproduce this; where do we go from > here? > Perhaps an strace will be the only way to debug it. For MSYS strace is only available with a debugging version of the dll. Earnie |
From: Keith M. <kei...@us...> - 2007-11-26 19:41:01
|
On Mon, 2007-11-26 at 08:03 -0500, Earnie Boyd wrote: > What type of file system is the share? I can see this being an issue > if /somedir/cvs reports /SOMEDIR/CVS instead with the stat function. It's NTFS, but I don't think that's the issue here. If it is, then this this is another example of why it is wrong to pervert the case retentive property of Win32 file systems in an attempt to perpetuate the myth that this somehow can pretend case sensitivity, when the reality is that such files systems are case *insensitive*. I don't want to reopen that old argument. I remain convinced that 99.9% of the time that is the wrong thing to do; it will surely turn around and bite you. You failed to convince me otherwise before; I see no reason to change this opinion. > > It is disturbing that you cannot reproduce this; where do we go from > > here? > > Perhaps an strace will be the only way to debug it. For MSYS strace > is only available with a debugging version of the dll. Ultimately, we may need to resort to that, but first please review my other follow up post. I may not be able to reproduce this myself, since I've performed a clean MSYS-1.0.11 install. However, I have kept the original installation in a separate tree, so can run tests in that if any likely avenue of exploration becomes apparent. Regards, Keith. |
From: Keith M. <kei...@us...> - 2007-11-26 19:40:55
|
On Sun, 2007-11-25 at 23:23 +0000, Keith Marshall wrote: > > 1) I created a share on an old Windows 95 box, full permissions, no > > password. > > Hmm. IIRC, I have R/W permission, but not full control; I can't > confirm that right now, but will check it tomorrow. Ok, done that. I have:-- Full Control -- no Modify -- yes Read & Execute -- yes List Folder Contents -- yes Read -- yes Write -- yes all of which are inherited from the root of the share. > Access to the share is via the Win2K domain authentication, and I do > have to supply a password for login to the domain. After successful domain login, the above access control attributes are defined, not for me as an individual user, but for a group of which I am a member. > [...] > It is disturbing that you cannot reproduce this; where do we go from > here? FWIW, my MSYS installation was created by unpacking the MSYS-1.0.11 components over the top of an existing MSYS-1.0.10 installation, (or maybe a very early MSYS-1.0.11 snapshot, I can't rember which now), and has evolved incrementally, as updates have become available. I've just blown that away, by unpacking only the current MSYS-1.0.11 components into a completely empty sibling of the original MSYS-1.0.11 directory, then quitting all MSYS sessions, renaming MSYS-1.0.11 as MSYS-1.0.11-old and its new sibling as MSYS-1.0.11, and opening a new MSYS session. So, now I've got a completely virgin MSYS-1.0.11, up and running with only the unadulterated base system components installed. I then added cvs-1.11.22-MSYS-1.0.11.tar.bz2 and vim-7.1-MSYS-1.0.11.tar.bz2, from the supplementary tools package. Now, when I try to checkout the same general package, from the same CVS repository as before, I see a pop up dialogue informing me, in no uncertain terms, that msys-crypt-0.dll or one of its components cannot be found in my $PATH. Hmm. Chuck's release notes didn't mention that dependency. Never mind; add crypt-1.1.1-MSYS-1.0.11.tar.bz2 to my new installation, and hurrah, checkout now seems to work as expected :-) (The puzzle now is: why did cvs not complain about this missing DLL dependency, when I updated it last week? I never had any such DLL in my original $PATH). With this fresh installation, the problem of vi vs. emacs as the log message editor, (now uses vi, *without* requiring an EDITOR export), and the failing multiple file commits also appear to have disappeared. I'm not sure if we still need a bug report, just to have a record of the anomaly of the missing diagnostic for the unsatisfied DLL dependency; it would be good to understand why that was happening. Any further thoughts? Regards, Keith. |
From: Cesar S. <ces...@gm...> - 2007-11-27 21:50:17
|
Keith Marshall wrote: > [...] > So, now I've got a completely virgin MSYS-1.0.11, up and running with > only the unadulterated base system components installed. I then added > cvs-1.11.22-MSYS-1.0.11.tar.bz2 and vim-7.1-MSYS-1.0.11.tar.bz2, from > the supplementary tools package. > [...] > add crypt-1.1.1-MSYS-1.0.11.tar.bz2 to my new installation, and hurrah, > checkout now seems to work as expected :-) > [...] > With this fresh installation, the problem of vi vs. emacs as the log > message editor, (now uses vi, *without* requiring an EDITOR export), and > the failing multiple file commits also appear to have disappeared. I'm glad you got past this cvs problem. As for me, I tried again with a share on a Linux SAMBA server, and my commit problem disappeared. Perhaps it's a Windows 95-only issue. > [...] > would be good to understand why that was happening. > > Any further thoughts? You could you compare the two MSYS trees, old and new. Then, start copying the files which are different from old to new, until cvs breaks. Or, copy from new to old, until cvs works. Regards, Cesar |
From: Charles W. <cwi...@us...> - 2007-12-06 03:58:48
|
Keith Marshall wrote: > I thought we might discuss this here, before I file a formal bug report. > This is looking like something of a show stopper [snip] > I've installed Chuck's most recent cvs-1.11.22-MSYS-1.0.11.tar.bz2, and > I've had no end of headaches since. The setup is as follows:-- [snip] > Can you investigate this please. I've been more or less offline for a few weeks (work+family), so sorry about the delay in responding. Does this issue still need investigating, or do we chalk it up to "at some point evolutionary upgrades of C:/msys/* are a bad idea; start over fresh"? -- Chuck ] |