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
> It is disturbing that you cannot reproduce this; where do we go from
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?