Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | - Creating filenames with special DOS characters '', '*', ':', '', | '', '|' is supported. | | - Creating files with special DOS device filename components (aux, | nul, prn) is supported. | | - File name are case sensitive if the OS and the underlying file system | supports it. Works on NTFS and NFS. Does not work on FAT and Samba | shares. Requires to change a registry key (see the user's guide). | Can be switched off on a per-mount base. But does/will setup.exe know what to do with a package containing such filenames? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiRYjsACgkQpiWmPGlmQSMcnwCg3q2JpXIOpDUhFBF9cs4vOfwN U88Ani5WrUfBySOpEM76hzNuEqnUdQLo =/Sml -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 01:56, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | - Creating filenames with special DOS characters '', '*', ':', '', | '', '|' is supported. | | - Creating files with special DOS device filename components (aux, | nul, prn) is supported. | | - File name are case sensitive if the OS and the underlying file system | supports it. Works on NTFS and NFS. Does not work on FAT and Samba | shares. Requires to change a registry key (see the user's guide). | Can be switched off on a per-mount base. But does/will setup.exe know what to do with a package containing such filenames? setup is a Win32 application. It won't know about this. Thou shalt not create packages which rely on case-sensitivity as part of the net distro. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | setup is a Win32 application. It won't know about this. Thou shalt | not create packages which rely on case-sensitivity as part of the | net distro. That's what I thought. So while managed mounts will no longer be needed for building, something still needs to be done for the packaging stage. So far my idea is to adapt cygport's make_managed_mount[1], but remove the mount/umount commands. I should also add a postinstall check to make sure illegal filenames aren't being installed without special handling. [1] http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/cygport/bin/make_managed_mount Any other ideas? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiRd50ACgkQpiWmPGlmQSPb/QCgxaNwHBXFaHGxYx4VsvIpUDqy mMIAn09jTDYpN3CiTnEoL13Rf4yKOw7n =Bpi4 -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 03:28, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | setup is a Win32 application. It won't know about this. Thou shalt | not create packages which rely on case-sensitivity as part of the | net distro. That's what I thought. So while managed mounts will no longer be needed for building, something still needs to be done for the packaging stage. So far my idea is to adapt cygport's make_managed_mount[1], but remove the mount/umount commands. I should also add a postinstall check to make sure illegal filenames aren't being installed without special handling. Illegal? The only illegal chars are slash and backslash, even on case-insensitive mounts. Does it really occur often that you have two filenames in the same dir only differing by case? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
Corinna Vinschen wrote: Illegal? The only illegal chars are slash and backslash, even on case-insensitive mounts. Does it really occur often that you have two filenames in the same dir only differing by case? I'd imagine aux and prn are still illegal, right? The numbers are fewer, these days, but there are still source packages out there that have 'aux/' subdirectories. -- Chuck
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 08:59, Charles Wilson wrote: Corinna Vinschen wrote: Illegal? The only illegal chars are slash and backslash, even on case-insensitive mounts. Does it really occur often that you have two filenames in the same dir only differing by case? I'd imagine aux and prn are still illegal, right? The numbers are fewer, these days, but there are still source packages out there that have 'aux/' subdirectories. No. Aux is fine now. As is nul, prn, com, ... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 15:23, Corinna Vinschen wrote: On Jul 31 08:59, Charles Wilson wrote: Corinna Vinschen wrote: Illegal? The only illegal chars are slash and backslash, even on case-insensitive mounts. Does it really occur often that you have two filenames in the same dir only differing by case? I'd imagine aux and prn are still illegal, right? The numbers are fewer, these days, but there are still source packages out there that have 'aux/' subdirectories. No. Aux is fine now. As is nul, prn, com, ... Btw., the list of changes attached to my original mail starting this thread http://cygwin.com/ml/cygwin-apps/2008-07/msg00060.html already mentioned that. This is one result of using NT functions exclusively for file access. What still won't work, though is to start an application called, for instance, aux.exe. The reason is that the CreateProcess call in spawn/exec is still a Win32 call which will treat this filename as a DOS device. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 15:30, Corinna Vinschen wrote: On Jul 31 15:23, Corinna Vinschen wrote: On Jul 31 08:59, Charles Wilson wrote: Corinna Vinschen wrote: Illegal? The only illegal chars are slash and backslash, even on case-insensitive mounts. Does it really occur often that you have two filenames in the same dir only differing by case? I'd imagine aux and prn are still illegal, right? The numbers are fewer, these days, but there are still source packages out there that have 'aux/' subdirectories. No. Aux is fine now. As is nul, prn, com, ... Btw., the list of changes attached to my original mail starting this thread http://cygwin.com/ml/cygwin-apps/2008-07/msg00060.html already mentioned that. This is one result of using NT functions exclusively for file access. What still won't work, though is to start an application called, for instance, aux.exe. The reason is that the CreateProcess call in spawn/exec is still a Win32 call which will treat this filename as a DOS device. Hang on, I have a workaround for that problem. It works fine when using the long path prefix \\?\ in the call to CreateProcessW. Unfortunately I had to add code to remove the \\?\ prefix for paths which fit into 260 chars to avoid problems with native Win32 apps so that's kind of a chicken-egg. Hmm, tricky. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | Illegal? The only illegal chars are slash and backslash, even on | case-insensitive mounts. Does it really occur often that you have two | filenames in the same dir only differing by case? For Cygwin I understand that, but you mean to say that *setup* will be able to install a file with a *:|? (The : is the most common case, usually within API docs, for obvious reasons.) If the only thing I have to worry about not installing is case-insensitive files in the same directory, I know of three cases (WindowMaker, gnome-chess, and liblouis) among 1650+ sources. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiR1LUACgkQpiWmPGlmQSPuWgCcCpCPoohY/4qxF++DZezCJZtD cPQAoI0SEFSv21YpVkguB8cgyfKk8jdD =pzfn -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 10:05, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | Illegal? The only illegal chars are slash and backslash, even on | case-insensitive mounts. Does it really occur often that you have two | filenames in the same dir only differing by case? For Cygwin I understand that, but you mean to say that *setup* will be able to install a file with a *:|? (The : is the most common case, usually within API docs, for obvious reasons.) Uh oh, you got me there. It shouldn't be ovberly complicated to tweak the untar code in setup to do the same special char conversion as Cygwin does, but, as usual, somebody has to do it. Maybe I'll look into that myself when I'm back in a couple of days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 31 16:10, Corinna Vinschen wrote: On Jul 31 15:30, Corinna Vinschen wrote: What still won't work, though is to start an application called, for instance, aux.exe. The reason is that the CreateProcess call in spawn/exec is still a Win32 call which will treat this filename as a DOS device. Hang on, I have a workaround for that problem. It works fine when using the long path prefix \\?\ in the call to CreateProcessW. Unfortunately I had to add code to remove the \\?\ prefix for paths which fit into 260 chars to avoid problems with native Win32 apps so that's kind of a chicken-egg. Hmm, tricky. I uploaded 1.7.0-23 to the release-2 area. It fixes the above problem. Now you can call an application called aux.exe just fine. Other changes: - Instead of restricting send/sendto/sendmsg calls to 64K, send data in 64K chunks under the hood to circumvent problem described in KB 201213. - Reworked tty code to handle inheritance better. - Remove some ancient code and better never used APIs. - Constify utmp/login API. - Fix for file systems which get confused when using NtQueryDirectoryFile with FileIdBothDirectoryInformation info class (just UNIXFS right now). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/28/2008 9:27 AM: | # check the window size after each command and, if necessary, | # update the values of LINES and COLUMNS. | shopt -s checkwinsize | | would it work in cygwin? Also; | | Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric? Hmm. Right now, bash _does_ set LINES and COLUMNS (as shell variables, you have to export them for children to see), but only after the first SIGWINCH, or if you have 'shopt -s checkwinsize', after the first non-builtin-command (ie. if checkwinsize is set, bash does not check window size after builtins - how weird is that?). At any rate, I already have a cygwin-specific patch for the upstream bug that lib/sh/winsize.c forgot to include termios.h. And blindly setting checkwinsize seems like it would slow things down: since SIGWINCH works (I tested in both cmd and urxvt), there is no need to slow down bash to check window size after every single command, when only window size changes are necessary. checkwinsize is primarily for those platforms that lack SIGWINCH. At any rate, you've given me an idea. Add this to /etc/profile, and $LINES and $COLUMNS will be automatically populated for all users, regardless of whether they use 'shopt -s checkwinsize': kill -s WINCH $$ - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPAOsACgkQ84KuGfSFAYB4+wCgnKRhiE1P6r/mKrOeR0BabG2n LjsAnR6CQyVTjw6huQBbHXU8qn4GvNyX =yxl6 -END PGP SIGNATURE-
Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
On Tue, July 29, 2008 12:37 pm, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/28/2008 9:27 AM: | # check the window size after each command and, if necessary, | # update the values of LINES and COLUMNS. | shopt -s checkwinsize | | would it work in cygwin? Also; | | Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric? Hmm. Right now, bash _does_ set LINES and COLUMNS (as shell variables, you have to export them for children to see), but only after the first SIGWINCH, or if you have 'shopt -s checkwinsize', after the first non-builtin-command (ie. if checkwinsize is set, bash does not check window size after builtins - how weird is that?). At any rate, I already have a cygwin-specific patch for the upstream bug that lib/sh/winsize.c forgot to include termios.h. And blindly setting checkwinsize seems like it would slow things down: since SIGWINCH works (I tested in both cmd and urxvt), there is no need to slow down bash to check window size after every single command, when only window size changes are necessary. checkwinsize is primarily for those platforms that lack SIGWINCH. At any rate, you've given me an idea. Add this to /etc/profile, and $LINES and $COLUMNS will be automatically populated for all users, regardless of whether they use 'shopt -s checkwinsize': kill -s WINCH $$ Hi Eric, So, let me get this straight, you _don't_ want/need me to add the shopt but you would like me to add the kill instruction? J.
base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
You can now call mkpasswd and mkgroup without any -l or -d parameter
and both tools choose by themselves what information to print, depending
on the machine being a domain member machine or not.
This should result in a matching change to the base-passwd package for
1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
without any parameter.
Could you please change that for us, John?
Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
parameters when calling mkpasswd and mkgroup. I've left the rest of the
script the same; that's OK?
Do we still want the base-files profile to have the message wrt group
names of mkpassword/mkgroup/mkgroup_l_d?
Are there any other changes wanted? For example, I think a comment about
MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time
to alter anything. Corinna; you use the tcsh shell don't you (I seem to
recall)? Are there any profile defaults we should put in for it?
I've added a few licenses; AFL (1.1, 1.2, 2.0, 2.1), Apache (1.0, 1.1,
2.0), Artistic (1, 2), BSD, GPL (2.0, 3.0), LGPL (2.0, 3.0), MIT, PHP (3).
Are there any others folks would like?
Is there anything more base-[files|password] could do for users?
My Debian /etc/profile sets EDITOR=vim useful? (not if you've not
installed vim I suppose; vi?)
/etc/bash.bashrc has the following in both Debian and Ubuntu (not a
suprise I suppose);
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
would it work in cygwin? Also;
# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- $1
return $?
else
return 127
fi
}
fi
could we do something similar? (Although, I wouldn't want to bring python
into base if I could help it) /usr/lib/command-no-found is a python
script as well.
Should we have a /etc/motd? (not that I know what should calls/displays
it in the cygwin env; /etc/profile?)
I'll package and upload tomorrow evening if nobody has any improvements.
J.
Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
On Jul 28 15:51, John Morrison wrote:
On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
You can now call mkpasswd and mkgroup without any -l or -d parameter
and both tools choose by themselves what information to print, depending
on the machine being a domain member machine or not.
This should result in a matching change to the base-passwd package for
1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
without any parameter.
Could you please change that for us, John?
Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
parameters when calling mkpasswd and mkgroup. I've left the rest of the
script the same; that's OK?
Yep, that's ok.
Do we still want the base-files profile to have the message wrt group
names of mkpassword/mkgroup/mkgroup_l_d?
Hmm, well, it doesn't hurt a lot, right? Using the new mkpasswd and
mkgroup will probably reduce printing this message a lot, if not
entirely.
Are there any other changes wanted? For example, I think a comment about
MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time
to alter anything.
Is that MAKE_MODE thingy supported at all in latest make? If so,
isn't MAKE_MODE=unix default anyway?
Corinna; you use the tcsh shell don't you (I seem to
recall)? Are there any profile defaults we should put in for it?
Yes, I'm using tcsh, but your scripts don't have to care for them
since everything's already done in csh.login and csh.cshrc. Including
setting MAKE_MODE=unix :)
My Debian /etc/profile sets EDITOR=vim useful? (not if you've not
installed vim I suppose; vi?)
I think setting EDITOR should be a user choice, but I'm not strongly
opposing the idea, especially given that I'm vim user anyway ;).
/etc/bash.bashrc has the following in both Debian and Ubuntu (not a
suprise I suppose);
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
would it work in cygwin? Also;
Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric?
# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- $1
return $?
else
return 127
fi
}
fi
Not for me.
Should we have a /etc/motd? (not that I know what should calls/displays
it in the cygwin env; /etc/profile?)
We get a default /etc/motd when the inetutils package has been installed.
I'll package and upload tomorrow evening if nobody has any improvements.
Cool, I'm looking forward,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
On Mon, Jul 28, 2008 at 05:27:50PM +0200, Corinna Vinschen wrote: On Jul 28 15:51, John Morrison wrote: On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote: You can now call mkpasswd and mkgroup without any -l or -d parameter and both tools choose by themselves what information to print, depending on the machine being a domain member machine or not. This should result in a matching change to the base-passwd package for 1.7. The /etc/postinstall/passwd-grp.sh script should call both tools without any parameter. Could you please change that for us, John? Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the parameters when calling mkpasswd and mkgroup. I've left the rest of the script the same; that's OK? Yep, that's ok. Do we still want the base-files profile to have the message wrt group names of mkpassword/mkgroup/mkgroup_l_d? Hmm, well, it doesn't hurt a lot, right? Using the new mkpasswd and mkgroup will probably reduce printing this message a lot, if not entirely. Are there any other changes wanted? For example, I think a comment about MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time to alter anything. Is that MAKE_MODE thingy supported at all in latest make? If so, isn't MAKE_MODE=unix default anyway? MAKE_MODE hasn't been supported in make since 2006. cgf
Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))
I just uploaded 1.7.0-21. It contains the following important changes: - Fix for the fix for the problem with native Win32 apps described in this thread: http://cygwin.com/ml/cygwin/2008-07/msg00457.html My first solution didn't work for applications started from a remote share path (//server/share/bin/foo). - Reworked mkpasswd and mkgroup tools a bit more. I added a -U option which allows to enumerate the standard UNIX accounts from a Samba server. I also added a way to define per-server uid/gid offsets (-D domain,offset). This allows to define the offsets in a reproducible way for later calls to mkpasswd/mkgroup. I also added a -b option to drop enumerating the builtin groups. This is handy when appending group information from another server to your already existing /etc/group file and you don't want to have to remove duplicate builtin groups manually. I updated the mkpasswd and mkgroup documentation under http://cygwin.com/1.7/cygwin-ug-net.html accordingly. - It turned out that on reading the user fstab file, the username used to construct the fstab filename was actually the Windows username, not the Cygwin username. I changed the startup code so that the Cygwin username is read from /etc/passwd before trying to read the user's fstab file. This also allows to define different user fstab files for users with the same name but from different domains. Assume you have created the mkpasswd file so that the usernames are fully qualified (real life example): $ mkpasswd -L coffee -D vinschen -u corinna COFFEE\corinna:unused:11003:10513:U-COFFEE\corinna,S-1-5-21-790525478-115176313-839522115-1003:/home/corinna:/bin/bash VINSCHEN\corinna:unused:21001:21125:U-VINSCHEN\corinna,S-1-5-21-9231407823-6179817828-4384181110-1001:/home/corinna:/bin/bash The /etc/profile.d/user-fstab.sh script from the latest base-cygwin package 0.7-1 will now actually create a different fstab file for both users on first logon: /etc/fstab.d/COFFEE/corinna /etc/fstab.d/VINSCHEN/corinna Yes, if the username contains / or \ as separator char, it will create the matching subdirs. If you defined another separator char like in -S+, it will of course just create plain files: /etc/fstab.d/COFFEE+corinna /etc/fstab.d/VINSCHEN+corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. I think that'll probably alter once there's a setup for 1.7. Ditto here. Waiting for setup for 1.7, then I'll rebuild all of my packages.
Re: New Cygwin 1.7.0-18 in release-2
On Jul 23 21:44, John Morrison wrote: On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote: I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. I think that'll probably alter once there's a setup for 1.7. Speaking personally I *need* my installation of cygwin and couldn't stand to be without it. (I will get 'round to patching the base packages, but I was/did hand these over to Igor; is he still around?) Igor is still around, yes. I didn't know (or forgot again) you handed over maintainership of the base packages. Igor? X under 1.7 is a requirement for me. Just wish I had the skills to get the latest version working. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. Once X works, that works for me :) Why is X so important for testing and building packages? I mean, the console window and rxvt exist, right? Personally I'm doing a lot in my Linux X console, connecting to my Windows machines via rdesktop and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in different directories, there should be no problem running 1.7 based rxvt/xterm in a 1.5 X server. We *really* need a new setup for 1.7 which doesn't access the Cygnus Solutions registry key anymore. Agreed :( J. (attempting to find some time!) Please with sugar? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote: On Jul 23 21:44, John Morrison wrote: On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote: I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. I think that'll probably alter once there's a setup for 1.7. Speaking personally I *need* my installation of cygwin and couldn't stand to be without it. (I will get 'round to patching the base packages, but I was/did hand these over to Igor; is he still around?) Igor is still around, yes. I didn't know (or forgot again) you handed over maintainership of the base packages. Igor? X under 1.7 is a requirement for me. Just wish I had the skills to get the latest version working. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. Once X works, that works for me :) Why is X so important for testing and building packages? testing and building no, but I suspect that for most maintainers (at least those with only one or two packages) the package is a 'thank you' back to cygwin for the environment so the stability of the environment is very important. I know that's why I started with the base- packages, 'cause I wanted to improve the 'out of the box' experience. I mean, the console window and rxvt exist, right? Personally I'm doing a lot in my Linux X console, connecting to my Windows machines via rdesktop and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in different directories, there should be no problem running 1.7 based rxvt/xterm in a 1.5 X server. I didn't know that. (attempting to find some time!) Please with sugar? I only have windows at work now and all my time is 'allocated' to projects... trying! If I don't get it done before the weekend I'll get a virtual machine running. Promise. J.
Re: New Cygwin 1.7.0-18 in release-2
On Jul 23 22:44, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | I'd be happy if even the most important packages have been rebuilt for | 1.7. So far the reactions from the package maintainers were somewhat | reticent. I know I've been holding back because of the apparent difficulties in transitioning between versions (even one way, not to mention back-and-forth), and until recently the uncertainty as to the timeframe for 1.7. I am at the point that I am ready to consider switching, however. I'm building OpenSSH as 1.5 and 1.7 version in different build dirs. I had no transitioning problems. Maybe that's because the build system is rather simple or something. Admittedly, except for openssh, openssl and syslog-ng and a local BETA vim7.2a I didn't bother to create more 1.7 packages so far. I was mainly interested in IPv6. | I'm still rather trying to smooth out the upgrade path so that there | are as little as possible manual changes left to the user. It will | be bumpy nevertheless... IOW you want to leave upgrading in the same root a possibility. Is it really worth it? Honestly, I don't know. Maybe it isn't. But so far I'm still thinking that a parallel 1.7 install should only be a temporary solution for developers and maintainers. It's not something I would like to drag on for years. That's why an upgrade path has some merits for me. | The problem so far is the Cygnus Solutions registry key and the | default name of the cygwin dir, C:\cygwin. When you try to install | 1.7, both shouldn't exist. So what I did is this: I understand the registry key is due to setup. But what's the problem with C:\cygwin? So far setup looks if c:\cygwin exists and if so, uses the install database in c:\cygwin\etc\setup accidentelly, even if you choose to install another installation to, say, D:\cygwin-2. | We *really* need a new setup for 1.7 which doesn't access the Cygnus | Solutions registry key anymore. Agreed, **ASAP**. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 24 10:17, John Morrison wrote: On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote: Please with sugar? I only have windows at work now and all my time is 'allocated' to projects... trying! If I don't get it done before the weekend I'll get a virtual machine running. Promise. Thanks! Btw., all my Windows machines are virtual machines. Even my domain controller is running in a VM :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | Honestly, I don't know. Maybe it isn't. But so far I'm still thinking | that a parallel 1.7 install should only be a temporary solution for | developers and maintainers. It's not something I would like to drag | on for years. That's why an upgrade path has some merits for me. I definitely agree that we don't want to support 1.5 anymore after 1.7 is stable. | So far setup looks if c:\cygwin exists and if so, uses the install | database in c:\cygwin\etc\setup accidentelly, even if you choose to | install another installation to, say, D:\cygwin-2. Would it suffice to rename /etc/setup/installed.db? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiIqxoACgkQpiWmPGlmQSPs+wCfbBHf8/82nFnMi0495IxmgZYH 9yYAoOIsocD8gruP4uyKhWWgCiDIPj7X =DRzP -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
On Jul 24 11:17, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | Honestly, I don't know. Maybe it isn't. But so far I'm still thinking | that a parallel 1.7 install should only be a temporary solution for | developers and maintainers. It's not something I would like to drag | on for years. That's why an upgrade path has some merits for me. I definitely agree that we don't want to support 1.5 anymore after 1.7 is stable. | So far setup looks if c:\cygwin exists and if so, uses the install | database in c:\cygwin\etc\setup accidentelly, even if you choose to | install another installation to, say, D:\cygwin-2. Would it suffice to rename /etc/setup/installed.db? I don't know, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | When 1.7 goes gold, the idea is to install over an 1.5 install. Or not. | It's the choice of the user. Installing over 1.5 is supported by the | base-cygwin package, which is supposed to convert the registry mount | points to /etc/fstab mount points. OTOH, a 1.7 install can coexist with | a 1.5 install on the same machine. The advantage of starting fresh with 1.7 would allow us to dump a lot of obsolete packages from the distro (both old versions of libs, and empty packages created for the purpose of smooth upgrades), and make some more changes leading up to 1.7 without creating more. It would mean some things would have to be rebuilt (e.g. diff requires libintl2), but IMHO everything should anyways be rebuilt for 1.7. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. | There's no roadmap. What's missing for a release is | | - A new setup.exe | | - The Cygwin utils are not quite up to speed | | - Documentation changes | | - Support by the package maintainers | | - Testing | | All of the above items could need a helping hand. If 1.7 isn't too | buggy, I plan to release 1.7 still in 2008. When that actually happens | doesn't depend on me. Cygwin 1.7 development has gone on for two years | and it comes with a lot of changes. Not all of them allow a 100% smooth | transition. | Eventually this release depends on the support it gets from all of you. I for one would like to catch up the distro to what I've made available in Ports. Could someone point me again to the current directions to install 1.7 in parallel to 1.5 on the same machine? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiHaZgACgkQpiWmPGlmQSO7jQCfXURX9AXZ5UaioPocdpte0W8o KokAniwdo2yASqmyM8JO+BMa5hIST7Jt =DgWy -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
On Jul 23 12:25, Yaakov (Cygwin Ports) wrote: Corinna Vinschen wrote: | When 1.7 goes gold, the idea is to install over an 1.5 install. Or not. | It's the choice of the user. The advantage of starting fresh with 1.7 would allow us to dump a lot of obsolete packages from the distro [...] but IMHO everything should anyways be rebuilt for 1.7. I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. I'm still rather trying to smooth out the upgrade path so that there are as little as possible manual changes left to the user. It will be bumpy nevertheless... | There's no roadmap. What's missing for a release is | | - A new setup.exe | | - The Cygwin utils are not quite up to speed | | - Documentation changes | | - Support by the package maintainers | | - Testing | | All of the above items could need a helping hand. If 1.7 isn't too | buggy, I plan to release 1.7 still in 2008. When that actually happens | doesn't depend on me. Cygwin 1.7 development has gone on for two years | and it comes with a lot of changes. Not all of them allow a 100% smooth | transition. | Eventually this release depends on the support it gets from all of you. I for one would like to catch up the distro to what I've made available in Ports. Cool. Could someone point me again to the current directions to install 1.7 in parallel to 1.5 on the same machine? The problem so far is the Cygnus Solutions registry key and the default name of the cygwin dir, C:\cygwin. When you try to install 1.7, both shouldn't exist. So what I did is this: - Rename C:\cygwin to C:\cygwin-1.5. Change this everywhere in the registry. - My HKCU Cygnus Solutions mount table is empty anyway, so it doesn't matter. Rename HKLM Cygnus Solutions to Cygnus Solutions 1.5. - Install Cygwin 1.7 with setup-1.7.exe into C:\cygwin. - Rename HKLM Cygnus Solutions to Cygnus Solutions 1.7 - Rename HKLM Cygnus Solutions 1.5 back to Cygnus Solutions. Since 1.7 doesn't use the above registry key, it doesn't matter for running 1.7. Just when calling setup-1.7 for an update, the registry key rename orgy starts again. We *really* need a new setup for 1.7 which doesn't access the Cygnus Solutions registry key anymore. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 21 18:42, Yaakov (Cygwin Ports) wrote: I've considered making the switch, as the new features in 1.7 (namely IPv6 and wchar functions) would make porting *much* easier. It might also provide the chance to finally close the gap between Ports and the distro, and generally improve our packaging scheme at the same time. OTOH I don't have only myself to think about; with all my packages, I doubt that I'll be able to support 1.5 any more after I switch. Not even pure security updates? It would help if I could get some clarification on: *) When 1.7 goes gold (and I don't mean binutils!), is the recommended upgrade path going to be in the same (Windows) tree, or to start fresh in a new directory? When 1.7 goes gold, the idea is to install over an 1.5 install. Or not. It's the choice of the user. Installing over 1.5 is supported by the base-cygwin package, which is supposed to convert the registry mount points to /etc/fstab mount points. OTOH, a 1.7 install can coexist with a 1.5 install on the same machine. *) Is gcc-4.3 in the near future for 1.7? Will gcc define _GLIBCXX_USE_WCHAR_T? Will it provide shared libgcc, libstdc++, etc? That's one for Dave to answer. *) Is there a roadmap of what needs to be done for 1.7? I know you don't want to provide a date, but some focus and perspective would be helpful. There's no roadmap. What's missing for a release is - A new setup.exe - The Cygwin utils are not quite up to speed - Documentation changes - Support by the package maintainers - Testing All of the above items could need a helping hand. If 1.7 isn't too buggy, I plan to release 1.7 still in 2008. When that actually happens doesn't depend on me. Cygwin 1.7 development has gone on for two years and it comes with a lot of changes. Not all of them allow a 100% smooth transition. Eventually this release depends on the support it gets from all of you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))
I just uploaded 1.7.0-20. It contains the following important changes: - Fix for the problem with native Win32 apps described in this thread: http://cygwin.com/ml/cygwin/2008-07/msg00457.html - Reworked mkpasswd and mkgroup tools including the documentation. The usage changed and you have some additional options to create unique usernames especially for multi-domain environments. You can now call mkpasswd and mkgroup without any -l or -d parameter and both tools choose by themselves what information to print, depending on the machine being a domain member machine or not. This should result in a matching change to the base-passwd package for 1.7. The /etc/postinstall/passwd-grp.sh script should call both tools without any parameter. Could you please change that for us, John? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 14:09, Corinna Vinschen wrote: On Jul 17 18:18, Eric Blake wrote: Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading to the new cygwin1.dll today, I'm now suffering from an inability to modify files on a shared drive on my work machine. I can create empty files and remove existing files just fine, but get access denied on any attempt to change contents. The -1 for owner and group looks fishy as well. [...] The real problem is exactly what I describe in the comment in fhandler_base::open(). Apparently, creating the file and sending the security descriptor to the server is a two step approach. So Samba creates the file first, and then, afterwards, Windows sends the request to change the security descriptor of the file. Now Samba can't map SID-uid and returns STATUS_ACCESS_DENIED. But there seems to be no knowledge that the two actions are actually one system call in Windows. So Samba doesn't remove the file, but still, NtCreateFile failed. Bummer. I have a local workaround which I'll apply in a minute. However, I never really understood why the mapping from the Windows SID to the UNIX user fails, even though the user has been successfully authenticated before. I have written a clueless mail to the samba developers list. Maybe they can enlighten me. They don't so far. However, as a side note, with acl on, you currently don't see user/group info in `ls -l', if your machines are not in fully Windows domain integrated. With the latest incarnation of mkpasswd and mkgroup (from CVS, not fully functional in 1.7.0-20), you can now ask your Samba machine for their passwd and group information: $ mkpasswd -L samba-machine /etc/passwd $ mkgroup -L samba-machine /etc/group At least this works for me. Unfortunately Samba doesn't enumerate the UNIX user and group information from its own /etc/passwd and /etc/group files. For instance the user root is S-1-22-1-0, the group root is S-1-22-2-0. That's what you see in the Windows Explorer Security tab as Unix User\root and Unix Group\root. Apparently these are never enumerated, only returned in calls to LookupAccountSid and LookupAccountName. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | again I would like to encourage the Cygwin maintainers, to try the new | Cygwin 1.7.0 release and to look for problems in their packages which | might be a result of the fairly massive changes in Cygwin 1.7. I | attached a list of the changes below. The latest changes are: I've considered making the switch, as the new features in 1.7 (namely IPv6 and wchar functions) would make porting *much* easier. It might also provide the chance to finally close the gap between Ports and the distro, and generally improve our packaging scheme at the same time. OTOH I don't have only myself to think about; with all my packages, I doubt that I'll be able to support 1.5 any more after I switch. It would help if I could get some clarification on: *) When 1.7 goes gold (and I don't mean binutils!), is the recommended upgrade path going to be in the same (Windows) tree, or to start fresh in a new directory? *) Is gcc-4.3 in the near future for 1.7? Will gcc define _GLIBCXX_USE_WCHAR_T? Will it provide shared libgcc, libstdc++, etc? *) Is there a roadmap of what needs to be done for 1.7? I know you don't want to provide a date, but some focus and perspective would be helpful. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiFHuIACgkQpiWmPGlmQSOYMACfUJJNNcUFVxtD+PYv4SSpaVIh kJUAnRF44vDumN4ScJX/sjcgly9lO/9M =xoP5 -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
--- Corinna Vinschen ha scritto: On Jul 18 13:56, Christopher Faylor wrote: On Fri, Jul 18, 2008 at 07:10:10PM +0200, Corinna Vinschen wrote: On Jul 18 18:36, Marco Atzeri wrote: Is it still unable to handle empty tarball ? ... of a certain type, yes, unfortunately. Fortunately it doesn't stop the whole setup process, it just prints an error message and asks for user input. Actually I don't think it can handle any type of empty tarball can it? I don't know. I thought it handles one type and complains about the other. I didn't actually test it. for me complained on: gcc-3.4.4-3.tar.bz2 for reading: Invalid or unsupported tar format tetex-3.0.0-3.tar.bz2 for reading: Invalid or unsupported tar format end it is a bit boring on a long installation to wait for click to continue :-) Corinna Marco Posta, news, sport, oroscopo: tutto in una sola pagina. Crea l#39;home page che piace a te! www.yahoo.it/latuapagina
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 15:28, Bill Hoffman wrote: Corinna Vinschen wrote: Download a 1.7 distro using http://cygwin.com/setup-1.7.exe Cygwin 1.7 and 1.5 can run in parallel sessions on the same machine, but the installation in parallel needs some manual intervention. Setup.exe is not yet using the new registry location and will happily install into your 1.5 installation dir... Are there any instructions on exactly how to do this? I tried to install both of them on my machine. I told setup-1.7 to install into a separate directory, however, all of the other registry stuff that keeps track of what is installed seems to be used as well. So, it installed some stuff, but not everything. The resulting install could not run programs because of missing dll's. You have to rename the Cygnus Solutions registry key and also rename the Cygwin 1.5 dir to something other than C:/cygwin. Then install 1.7 into, say, C:/cygwin-1.7. Then rename the Cygnus Solutions registry key to, for instance, Cygnus Solutions 1.7 (it's not used in 1.7 anyway) and rename the old 1.5 key back to Cygnus Solutions. We would really need a new setup.exe. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)
On Jul 17 17:55, Corinna Vinschen wrote: Hi, again I would like to encourage the Cygwin maintainers, to try the new Cygwin 1.7.0 release and to look for problems in their packages which might be a result of the fairly massive changes in Cygwin 1.7. I attached a list of the changes below. The latest changes are: - Changes in mkpasswd/mkgroup and in seteuid() should result in more correct user tokens in AD domains. Try the LSA module. - Case-sensitivity on NTFS and NFS and mount option posix=[0|1]. - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount option acl/noacl. I just uploaded 1.7.0-19. I made the following changes - Workaround for the problem Eric reported, a permission denied when creating files on a Samba shares mounted with acl option (default, replacement for CYGWIN=ntsec option, see comment in default /etc/fstab file). - Removed the CYGWIN=binmode option. We're now always using binmode for pipes and stuff. - ls // now lists all SMB servers in all accessible domains and workgroups, instead of just the servers in the machine's member domain or workgroup. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 17 18:18, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/17/2008 9:55 AM: | Hi, | | again I would like to encourage the Cygwin maintainers, to try the new | Cygwin 1.7.0 release and to look for problems in their packages which | might be a result of the fairly massive changes in Cygwin 1.7. I | attached a list of the changes below. The latest changes are: | | - Changes in mkpasswd/mkgroup and in seteuid() should result in more | correct user tokens in AD domains. Try the LSA module. | - Case-sensitivity on NTFS and NFS and mount option posix=[0|1]. | - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount | option acl/noacl. Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading to the new cygwin1.dll today, I'm now suffering from an inability to modify files on a shared drive on my work machine. I can create empty files and remove existing files just fine, but get access denied on any attempt to change contents. The -1 for owner and group looks fishy as well. Drive U is apparently a Samba drive. Is that in a Windows domain? If not, try the noacl mount option. It's equivalent to what was CYGWIN=nosmbntsec before. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 09:34, Corinna Vinschen wrote: On Jul 17 18:18, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/17/2008 9:55 AM: | Hi, | | again I would like to encourage the Cygwin maintainers, to try the new | Cygwin 1.7.0 release and to look for problems in their packages which | might be a result of the fairly massive changes in Cygwin 1.7. I | attached a list of the changes below. The latest changes are: | | - Changes in mkpasswd/mkgroup and in seteuid() should result in more | correct user tokens in AD domains. Try the LSA module. | - Case-sensitivity on NTFS and NFS and mount option posix=[0|1]. | - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount | option acl/noacl. Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading to the new cygwin1.dll today, I'm now suffering from an inability to modify files on a shared drive on my work machine. I can create empty files and remove existing files just fine, but get access denied on any attempt to change contents. The -1 for owner and group looks fishy as well. Drive U is apparently a Samba drive. Is that in a Windows domain? If not, try the noacl mount option. It's equivalent to what was CYGWIN=nosmbntsec before. Hmm, I can reproduce it and now that I see it myself I can see how this is a problem with cygdrive mounts. I assume the best way to handle this would be to set Samba drives to noacl by default, right? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 09:54, Corinna Vinschen wrote: On Jul 18 09:34, Corinna Vinschen wrote: On Jul 17 18:18, Eric Blake wrote: Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading to the new cygwin1.dll today, I'm now suffering from an inability to modify files on a shared drive on my work machine. I can create empty files and remove existing files just fine, but get access denied on any attempt to change contents. The -1 for owner and group looks fishy as well. Drive U is apparently a Samba drive. Is that in a Windows domain? If not, try the noacl mount option. It's equivalent to what was CYGWIN=nosmbntsec before. Hmm, I can reproduce it and now that I see it myself I can see how this is a problem with cygdrive mounts. I assume the best way to handle this would be to set Samba drives to noacl by default, right? OTOH, I can't choose different mount options for different per cygdrive mounted drives. All cydrives share the same options. How should we solve that? I hope that doesn't mean we still need the global (no)smbntsec option... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 10:09, Corinna Vinschen wrote: On Jul 18 09:54, Corinna Vinschen wrote: On Jul 18 09:34, Corinna Vinschen wrote: On Jul 17 18:18, Eric Blake wrote: Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading to the new cygwin1.dll today, I'm now suffering from an inability to modify files on a shared drive on my work machine. I can create empty files and remove existing files just fine, but get access denied on any attempt to change contents. The -1 for owner and group looks fishy as well. Drive U is apparently a Samba drive. Is that in a Windows domain? If not, try the noacl mount option. It's equivalent to what was CYGWIN=nosmbntsec before. Hmm, I can reproduce it and now that I see it myself I can see how this is a problem with cygdrive mounts. I assume the best way to handle this would be to set Samba drives to noacl by default, right? OTOH, I can't choose different mount options for different per cygdrive mounted drives. All cydrives share the same options. How should we solve that? I hope that doesn't mean we still need the global (no)smbntsec option... For a start, I don't think we have to go back to smbntsec. The real problem is exactly what I describe in the comment in fhandler_base::open(). Apparently, creating the file and sending the security descriptor to the server is a two step approach. So Samba creates the file first, and then, afterwards, Windows sends the request to change the security descriptor of the file. Now Samba can't map SID-uid and returns STATUS_ACCESS_DENIED. But there seems to be no knowledge that the two actions are actually one system call in Windows. So Samba doesn't remove the file, but still, NtCreateFile failed. Bummer. I have a local workaround which I'll apply in a minute. However, I never really understood why the mapping from the Windows SID to the UNIX user fails, even though the user has been successfully authenticated before. I have written a clueless mail to the samba developers list. Maybe they can enlighten me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
--- Corinna Vinschen ha scritto: Hi, Hi Corinna, Download a 1.7 distro using http://cygwin.com/setup-1.7.exe Is it still unable to handle empty tarball ? Bye Marco Posta, news, sport, oroscopo: tutto in una sola pagina. Crea l#39;home page che piace a te! www.yahoo.it/latuapagina
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 18:36, Marco Atzeri wrote: --- Corinna Vinschen ha scritto: Download a 1.7 distro using http://cygwin.com/setup-1.7.exe Is it still unable to handle empty tarball ? ... of a certain type, yes, unfortunately. Fortunately it doesn't stop the whole setup process, it just prints an error message and asks for user input. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Fri, Jul 18, 2008 at 07:10:10PM +0200, Corinna Vinschen wrote: On Jul 18 18:36, Marco Atzeri wrote: --- Corinna Vinschen ha scritto: Download a 1.7 distro using http://cygwin.com/setup-1.7.exe Is it still unable to handle empty tarball ? ... of a certain type, yes, unfortunately. Fortunately it doesn't stop the whole setup process, it just prints an error message and asks for user input. Actually I don't think it can handle any type of empty tarball can it? I created them with tar -T /dev/null -cjf foo.tar.bz2 but I think setup.exe still complains about those type of tar files. cgf
Re: New Cygwin 1.7.0-18 in release-2
On Jul 18 13:56, Christopher Faylor wrote: On Fri, Jul 18, 2008 at 07:10:10PM +0200, Corinna Vinschen wrote: On Jul 18 18:36, Marco Atzeri wrote: Is it still unable to handle empty tarball ? ... of a certain type, yes, unfortunately. Fortunately it doesn't stop the whole setup process, it just prints an error message and asks for user input. Actually I don't think it can handle any type of empty tarball can it? I don't know. I thought it handles one type and complains about the other. I didn't actually test it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
Corinna Vinschen wrote: Download a 1.7 distro using http://cygwin.com/setup-1.7.exe Cygwin 1.7 and 1.5 can run in parallel sessions on the same machine, but the installation in parallel needs some manual intervention. Setup.exe is not yet using the new registry location and will happily install into your 1.5 installation dir... Are there any instructions on exactly how to do this? I tried to install both of them on my machine. I told setup-1.7 to install into a separate directory, however, all of the other registry stuff that keeps track of what is installed seems to be used as well. So, it installed some stuff, but not everything. The resulting install could not run programs because of missing dll's. Thanks. -Bill
Re: New Cygwin 1.7.0-18 in release-2
Corinna Vinschen wrote: Actually I don't think it can handle any type of empty tarball can it? I don't know. I thought it handles one type and complains about the other. I didn't actually test it. It can handle the type created by bzip2 /dev/null but not the tar -T /dev/null type. I haven't had time to fix that yet, and I apologize for letting setup remain in this state for so long. However, aside from having to dismiss a popup it should be inconsequential -- the resulting installation is not affected. Brian
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/17/2008 9:55 AM: | Hi, | | again I would like to encourage the Cygwin maintainers, to try the new | Cygwin 1.7.0 release and to look for problems in their packages which | might be a result of the fairly massive changes in Cygwin 1.7. I | attached a list of the changes below. The latest changes are: | | - Changes in mkpasswd/mkgroup and in seteuid() should result in more | correct user tokens in AD domains. Try the LSA module. | - Case-sensitivity on NTFS and NFS and mount option posix=[0|1]. | - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount | option acl/noacl. Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading to the new cygwin1.dll today, I'm now suffering from an inability to modify files on a shared drive on my work machine. I can create empty files and remove existing files just fine, but get access denied on any attempt to change contents. The -1 for owner and group looks fishy as well. $ touch /cygdrive/u/file $ echo hi /cygdrive/u/file bash: /cygdrive/u/file: Permission denied $ ls -lF /cygdrive/u/file - -rwxrw-r-- 1 0 Jul 17 18:08 /cygdrive/u/file* $ rm /cygdrive/u/file $ echo hi /cygdrive/u/file bash: /cygdrive/u/file: Permission denied $ ls -lF /cygdrive/u/file - -rwxrw-r-- 1 0 Jul 17 18:08 /cygdrive/u/file* $ ls -niF /cygdrive/u/file 7573255750942747 -rwxrw-r-- 1 4294967295 4294967295 0 Jul 17 18:08 /cygdrive/u/file* $ od -tx1 /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session\ Manager/kernel/obcaseinsensitive 000 00 00 00 00 004 $ mount C:\cygwin-2\bin on /usr/bin type ntfs (binmode,system) C:\cygwin-2\lib on /usr/lib type ntfs (binmode,system) C:\cygwin\home on /home type ntfs (binmode,system) C:\cygwin-2 on / type ntfs (binmode,system) c: on /cygdrive/c type ntfs (binmode,posix=0,noumount,user) u: on /cygdrive/u type smbfs (binmode,posix=0,noumount,user) $ volinfo /cygdrive/u Device Type: 7 Characteristics: 10 Volume Name: eblake Serial Number : 316278793 Max Filenamelength : 255 Filesystemname : NTFS Flags : b ~ FILE_CASE_SENSITIVE_SEARCH : TRUE ~ FILE_CASE_PRESERVED_NAMES : TRUE ~ FILE_UNICODE_ON_DISK: FALSE ~ FILE_PERSISTENT_ACLS: TRUE ~ FILE_FILE_COMPRESSION : FALSE ~ FILE_VOLUME_QUOTAS : FALSE ~ FILE_SUPPORTS_SPARSE_FILES : FALSE ~ FILE_SUPPORTS_REPARSE_POINTS: FALSE ~ FILE_SUPPORTS_REMOTE_STORAGE: FALSE ~ FILE_VOLUME_IS_COMPRESSED : FALSE ~ FILE_SUPPORTS_OBJECT_IDS: FALSE ~ FILE_SUPPORTS_ENCRYPTION: FALSE ~ FILE_NAMED_STREAMS : FALSE ~ FILE_READ_ONLY_VOLUME : FALSE ~ FILE_SEQUENTIAL_WRITE_ONCE : FALSE ~ FILE_SUPPORTS_TRANSACTIONS : FALSE Need an strace? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh/4TwACgkQ84KuGfSFAYBMbQCgoOcoxxLn2BfjBotyh92EOf6t C1YAoLsSga/e6271Tfe1Aal4XyHh3C3i =jDOI -END PGP SIGNATURE-
