New Cygwin 1.7.0-18 in release-2

New Cygwin 1.7.0-18 in release-2

[Corinna Vinschen]

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".

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...

Brian, any timeframe for a new setup for 1.7?

I made new documentation available, which just isn't yet finished.  Have
a look into http://cygwin.com/1.7/cygwin-ug-net.html.  The missing
pieces are changes to the utilities, half of the "NT Security" chapter
is still old, and some bits of information on NFS access.  A new FAQ is
also not available yet.  However, the docs already explain how to use
the new /etc/fstab and /etc/fstab.d/${USER} files, the available
mount options, how to tweak the system to get case-sensitivity, etc.

Please test and please create new packages for 1.7 as far as necessary.
I really think we should prepare to push out an official 1.7 release in
2008.


Corinna

--- List of changes:

OS releated changes:
--------------------

- Windows 95, 98 and Me are not supported anymore.  The new DLL will
  not run on any of these systems.

File Access related changes:
----------------------------

- Mount points are no longer stored in the registry.  Use /etc/fstab
  and /etc/fstab.d/$USER instead.  Mount points created with mount(1)
  are only local to the current session and disappear when the last
  Cygwin process in the session exits.

- PATH_MAX is now 4096.  Internally, path names can be as long as the
  underlying OS can handle (32K).
  
- UTF-8 filenames are supported now.  So far, this requires to set
  the environment variable CYGWIN to contain "codepage:utf8", but this
  will likely disappear in a few weeks time.  The setting of $LANG or
  $LC_CTYPE will be used instead.

- The CYGWIN environment variable options "ntsec" and "smbntsec" have
  been replaced by the per-mount option "acl"/"noacl".

- The CYGWIN environment variable option "check_case" has been removed.

- 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.

- unlink(2) and rmdir(2) try very hard to remove files/directories even
  if they are currently accessed or locked.  This is done by utilizing
  the hidden recycle bin directories and marking the files for deletion.

- rename(2) rewritten to be more POSIX conformant.

- Add st_birthtim member to struct stat.

- File locking is now advisory, not mandatory anymore.  The fcntl(2) and
  the new lockf(2) APIs create and maintain locks with POSIX semantics,
  the flock(2) API creates and maintains locks with BSD semantics.
  POSIX and BSD locks are independent of each other.

- Implement atomic O_APPEND mode.

- Handle NTFS native symlinks available since Vista/2008 as symlinks.

- Recognize NFS shares and handle them using native mechanisms.
  Recognize and create real symlinks on NFS shares.  Get correct
  stat(2) information and set real mode bits on open(2), mkdir(2)
  and chmod(2).

- Recognize Netapp DataOnTap drives and fix inode number handling.

- Recognize Samba version beginning with Samba 3.0.28a using the new
  extended version information negotiated with the Samba developers.

- Support Linux-like extended attributes ([fl]getxattr, [fl]listxattr,
  [fl]setxattr, [fl]removexattr).

- New file conversion API for conversion from Win32 to POSIX path and
  vice versa (cygwin_conv_path, cygwin_create_path, cygwin_conv_path_list).

- New openat family of functions: openat, faccessat, fchmodat, fchownat,
  fstatat, futimesat, linkat, mkdirat, mkfifoat, mknodat, readlinkat, renameat,
  symlinkat, unlinkat.

- Other new APIs: posix_fadvise, posix_fallocate, funopen, fopencookie,
  open_memstream, fmemopen, fdopendir.

Network related changes:
------------------------

- New implementation for blocking sockets and select on sockets which
  is supposed to allow POSIX-compatible sharing of sockets between
  threads and processes.

- Restrict send/sendto/sendmsg to send never more than 64K to circumvent
  internal buffer problem in WinSock.  (May need rework)

- IPv6 support.  New API getaddrinfo, getnameinfo, freeaddrinfo,
  gai_strerror, in6addr_any, in6addr_loopback.  On IPv6-less systems,
  replacement functions are available for IPv4.  On systems with IPv6
  enabled, the underlying WinSock functions are used.  While I tried
  hard to get the functionality as POSIXy as possible, keep in mind that
  a *fully* conformant implementation of getaddrinfo and other stuff is
  only available starting with Windows Vista/2008.

- Resolver functions (res_init, res_query, res_search, res_querydomain,
  res_mkquery, res_send, dn_comp, dn_expand) are now part of Cygwin.
  Applications don't have to link against minires anymore.  Actually,
  this *is* the former libminires.a.

- rcmd is now implemented inside of Cygwin, instead of calling the
  WinSock function.  This allows rsh(1) usage on Vista/2008, which
  dropped this function from WinSock.

- Define multicast structures in netinet/in.h.  Note that fully
  conformant multicast support is only available beginning with Vista/2008.

- Improve get_ifconf.  Redefine struct ifreq and subsequent datastructures
  to be able to keep more information.  Support SIOCGIFINDEX, SIOCGIFDSTADDR
  and the Cygwin specific SIOCGIFFRNDLYNAM.  Support real interface flags
  on systems supporting them.

- Other new APIs: bindresvport, bindresvport_sa, iruserok_sa, rcmd_af,
  rresvport_af.  getifaddrs, freeifaddrs, if_nametoindex, if_indextoname,
  if_nameindex, if_freenameindex.

- Add /proc/net/if_inet6.

Device related changes:
-----------------------

- Reworked pipe implementation which uses overlapped IO to create
  more reliable interruptible pipes and fifos.

- Reworked pipe handling for better speed and better support for signal
  processing.

- Improved fifo handling.

- Detect when a stdin/stdout which looks like a pipe is really a tty.
  Among other things, this allows a debugged application to recognize that
  it is using the same tty as the debugger.

- Support UTF-8 in console window.

- Support up to 64 serial interfaces using /dev/ttyS0 - /dev/ttyS63.

- Support up to 128 raw disk drives /dev/sda - /dev/sddx.

- New API: posix_openpt.

Other POSIX related changes:
----------------------------

- Implement pthread_kill(thread, 0) as per POSIX.

- New API for POSIX IPC:
  Named semaphores: sem_open, sem_close, sem_unlink.
  Message queues: mq_open, mq_getattr, mq_setattr, mq_notify, mq_send,
  mq_timedsend, mq_receive, mq_timedreceive, mq_close, mq_unlink.
  Shared memory: shm_open, shm_unlink.

- Only declare expected functions in <strings.h>, don't include <string.h>
  from here.

- New APIs: asnprintf, dprintf, _Exit, vasnprintf, vdprintf, confstr,
  posix_madvise, posix_memalign, exp10, exp10f, pow10, pow10f, lrint,
  lrintf, rint, rintf, llrint, llrintf, llrintl, lrintl, rintl insque,
  remque, sys_sigabbrev, strcasestr, stpcpy, stpncpy, wcpcpy, wcpncpy,
  wcstol, wcstoll, wcstoul, wcstoull, wcsxfrm.

Security related changes:
-------------------------

- Getting a domain user's groups is hopefully more bulletproof now.

- Cygwin now comes with a real LSA authentication package.  This must
  be manually installed by a privileged user using the /bin/cyglsa-config
  script.  The advantages and disadvantages are noted in
  http://cygwin.com/ml/cygwin-developers/2006-11/msg00000.html

- Drop CYGWIN=ntea fake.

Miscellanous:
-------------

- Fallout from the long path names: If the current working directory is
  longer than 260 bytes, or if the current working directory is a virtual
  path (like /proc, /cygdrive, //server), don't call native Win32 programs
  since they don't understand these paths.

- On the first usage of a DOS path (C:\foo, \\foo\bar), the Cygwin DLL
  emits a scary warning that DOS paths shouldn't be used.  There's also
  the new CYGWIN=nodosfilewarning setting to disable that.

- Allow environment of arbitrary size instead of a maximum of 32K.

- Detect and report a missing DLL on process startup.

- Add /proc/registry32 and /proc/registry64 paths to access 32 bit and
  64 bit registry on 64 bit systems.

- Align /proc/cpuinfo more closly to Linux content.

- Optimized strstr and memmem implementation.

- Remove backwards compatibility with old signal masks (some *very* old
  programs which use signal masks may no longer work correctly).

- Numerous bug fixes.

- Probably a couple of entirely new bugs.


-- 
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

[Eric Blake]

-----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
0000000 00 00 00 00
0000004
$ 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             ebb9@byu.net
-----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-----

Re: New Cygwin 1.7.0-18 in release-2

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Marco Atzeri]

--- 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'home page che piace a te!
www.yahoo.it/latuapagina

Re: New Cygwin 1.7.0-18 in release-2

[Corinna Vinschen]

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

[Christopher Faylor]

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

[Corinna Vinschen]

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

[Bill Hoffman]

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

[Brian Dessent]

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

[Marco Atzeri]

--- 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'home page che piace a te!
www.yahoo.it/latuapagina

Re: New Cygwin 1.7.0-18 in release-2

[Corinna Vinschen]

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)

[Corinna Vinschen]

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

[Yaakov (Cygwin Ports)]

-----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]

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))

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Yaakov (Cygwin Ports)]

-----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

[Corinna Vinschen]

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

[John Morrison]

On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote:
> 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.

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?)

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 :)

> 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.

Definately.

>> 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.

Agreed :(

J.

(attempting to find some time!)

Re: New Cygwin 1.7.0-18 in release-2

[Yaakov (Cygwin Ports)]

-----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 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?

| 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?

| We *really* need a new setup for 1.7 which doesn't access the "Cygnus
| Solutions" registry key anymore.

Agreed, **ASAP**.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiH+q0ACgkQpiWmPGlmQSPHKQCg4CVTKqvlFcMoMedsx3DdO2W7
ErUAoN1WMf9kucpPgh/IBGhf/5PFtvLM
=77Hl
-----END PGP SIGNATURE-----

Re: New Cygwin 1.7.0-18 in release-2

[Corinna Vinschen]

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

[John Morrison]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Yaakov (Cygwin Ports)]

-----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

[Corinna Vinschen]

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: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))

[Corinna Vinschen]

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

[Andrew Schulman]

> > 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.

1.7.0-21 broken

[Corinna Vinschen]

On Jul 25 10:10, Corinna Vinschen wrote:
> I just uploaded 1.7.0-21.

Please ignore this for now.  There's a serious problem with this
release.  I'm investigating...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: 1.7.0-21 broken

[Corinna Vinschen]

On Jul 25 13:00, Corinna Vinschen wrote:
> On Jul 25 10:10, Corinna Vinschen wrote:
> > I just uploaded 1.7.0-21.
> 
> Please ignore this for now.  There's a serious problem with this
> release.  I'm investigating...

I uploaded 1.7.0-22 which hopefully fixes this issue.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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)))

[John Morrison]

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)))

[Corinna Vinschen]

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

[John Morrison]

On Mon, July 28, 2008 4:27 pm, Corinna Vinschen wrote:
> On Jul 28 15:51, John Morrison wrote:
>> On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
> Yep, that's ok.

Good :)

>> 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.

Doesn't hurt, but might speed up startup by a second or so... prob not
worth removing.

>> 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?

absolutely no idea.

>>   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 :)

Ok.  So the tcsh script includes csh.cshrc?  Should the bash package
include the bash.bashrc?

>> 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 ;).

Me too, but the user can always override this in their ~ files.

>> /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.

Ah, but I bet you've got just about everything installed anyway!  You also
know where/how to find this informtion.  We could knockup a script which
calls http://cygwin.com/cgi-bin2/package-grep.cgi?grep=<command>, cleans
up the html and writes it out?  It's more for the person who doesn't know
what package to install.  It'd be even easier if there was a plain text
version of the output then it'd just be curl :)  Is the source for the
package-grep.cgi available?

>> 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.

Okie, I've only installed base on my vm.

>> I'll package and upload tomorrow evening if nobody has any improvements.
>
> Cool, I'm looking forward,

Np, sorry it's take so long :(

J.

Re: base-[files|password] for 1.7

[Pierre A. Humblet]

----- Original Message ----- 
From: "Corinna Vinschen" <>
To: <cygwin-apps@cygwin.com>
Sent: Monday, July 28, 2008 11:27 AM
Subject: 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.


Looks like without argument the new mk{passwd/group} will dump the entire
passwd/group from the domain server. Some companies have tens of thousands
of names and that's why they weren't called with -l -d by default but with -l -c

The -c switch would only create an entry for the current user or the current primary group
WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
using only local info but mkgroup could not find the group name, so it was
calling it "mkgroup-l-d" .

The new mkgroup also has a -c option, which  gets the current primary group name.
That's great, but does it contact the server? If so, how does it behave when a domain
user installs cygwin while not connected to the domain server? That case generated
complaints in the past.

I also noticed that the new mkpasswd -c does not put a guess about the full user name
in the comment field
old -c:
p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
new -c
p-humblet:unused:11068:11031: U-W...         <== no p-humblet
{old,new} -d
p-humblet:unused:11068:11031:Pierre Humblet,U-W...

Pierre

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)))

[Christopher Faylor]

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: base-[files|password] for 1.7

[Corinna Vinschen]

On Jul 28 17:33, John Morrison wrote:
> On Mon, July 28, 2008 4:27 pm, Corinna Vinschen wrote:
> > On Jul 28 15:51, John Morrison wrote:
> >>   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 :)
> 
> Ok.  So the tcsh script includes csh.cshrc?  Should the bash package
> include the bash.bashrc?

I don't think so.  Eric?


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

[Corinna Vinschen]

On Jul 28 14:55, Pierre A. Humblet wrote:
> Looks like without argument the new mk{passwd/group} will dump the entire
> passwd/group from the domain server. Some companies have tens of thousands
> of names and that's why they weren't called with -l -d by default but with -l -c
> 
> The -c switch would only create an entry for the current user or the current primary group
> WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
> using only local info but mkgroup could not find the group name, so it was
> calling it "mkgroup-l-d" .

I thought it's a good idea to have the domain by default.  It's a bit
strange that a machine is running in a domain but as soon as another
user logs in, the passwd and possibly group information for this user
is missing.

Even if we drop back to using mkpasswd -l -c, I don't think it makes
sense to run mkgroup in a domain environment without fetching all
domain groups.

> The new mkgroup also has a -c option, which  gets the current primary
> group name.  That's great, but does it contact the server? If so, how

No.  The -c options only open the user token and fetch the name
information from a call to LookupAccountName(NULL, ...).  Since the
user information for the current user is cached on the local machine,
there's no server access.

> does it behave when a domain user installs cygwin while not connected
> to the domain server? That case generated complaints in the past.

Not for -c, but in the default case it will take some time until it
times out and won't print the domain groups.  Since that's only an
actual issue at installation time, where's the problem?

> I also noticed that the new mkpasswd -c does not put a guess about the full user name
> in the comment field
> old -c:
> p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
> new -c
> p-humblet:unused:11068:11031: U-W...         <== no p-humblet
> {old,new} -d
> p-humblet:unused:11068:11031:Pierre Humblet,U-W...

Why do you need that?  I was contemplating the idea to drop this
entirely.  I even contemplated the idea to remove the U-domain\user
entry from pw_gecos, plus the extra functionality in the
extract_nt_dom_user function in sec_auth.cc.  I rearranged it to use
the SID from the passwd entry and to call LookupAccountSid first. 
In theory there's no good reason to use that U-domain\user entry at all.
Extracting this information from the SID only makes much more sense,
IMHO.


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)))

[Eric Blake]

-----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             ebb9@byu.net
-----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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 7/29/2008 3:33 AM:
|> Ok.  So the tcsh script includes csh.cshrc?  Should the bash package
|> include the bash.bashrc?
|
| I don't think so.  Eric?

Right now, cygwin's /etc/bash.bashrc is a no-op.  I'm not sure what users
would like to see in a bash-specific startup file.  Also, upstream bash
does not automatically source /etc/bash.bashrc (or, as I've seen on some
Linux systems, /etc/bashrc); that would take a bash patch or an explicit
source command from within /etc/profile.  I don't mind taking ownership of
bash.bashrc, if you'd like me to do so, but what should I put in it?  It
seems easier to me to leave it as part of base-files, since it already
requires coordination with /etc/profile.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----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

iEYEARECAAYFAkiPBAkACgkQ84KuGfSFAYDuawCfQlroINtRLBB7xsceCX+YvJOb
T78AoLv617JMXLDx47QhAPaO9cIhbG5G
=+VC6
-----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)))

[John Morrison]

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.

Re: base-[files|password] for 1.7

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to John Morrison on 7/29/2008 5:56 AM:
|> 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?

Correct, the kill instruction is more efficient than the shopt - there is
no reason to poll for window changes after every command if the interrupt
for window changes works.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----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

iEYEARECAAYFAkiPBpcACgkQ84KuGfSFAYDqsQCg1NOdOC6i0nB16GMhSIqzcLWV
MC0AoMLD7TMrxjYn9E5Hwrt4Q3lObWEZ
=S+Vp
-----END PGP SIGNATURE-----

Re: base-[files|password] for 1.7

[Corinna Vinschen]

On Jul 29 06:01, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to John Morrison on 7/29/2008 5:56 AM:
> |> 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?
>
> Correct, the kill instruction is more efficient than the shopt - there is
> no reason to poll for window changes after every command if the interrupt
> for window changes works.

I think it doesn't work for console windows.  There's no automatic
message when the console window size changes.  There is some code
in Cygwin's console code (fhandler_console::send_winch_maybe), but
it only works when a console event is generated.  And then it isn't
called on key events.  For testing I added the call to the key event
so that the window size change is at least advertised when the next
key is pressed.

Chris, is there any good reason NOT to call send_winch_maybe on
a key event?


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

[Christopher Faylor]

On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>On Jul 29 06:01, Eric Blake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> According to John Morrison on 7/29/2008 5:56 AM:
>> |> 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?
>>
>> Correct, the kill instruction is more efficient than the shopt - there is
>> no reason to poll for window changes after every command if the interrupt
>> for window changes works.
>
>I think it doesn't work for console windows.  There's no automatic
>message when the console window size changes.  There is some code
>in Cygwin's console code (fhandler_console::send_winch_maybe), but
>it only works when a console event is generated.  And then it isn't
>called on key events.  For testing I added the call to the key event
>so that the window size change is at least advertised when the next
>key is pressed.
>
>Chris, is there any good reason NOT to call send_winch_maybe on
>a key event?

It only makes sense when there is a mouse event.  It would make more
sense to move the handling of SIGWINCH into the signal handler so that
the above works transparently.  I'll look into doing that.

cgf

Re: base-[files|password] for 1.7

[Pierre A. Humblet]

----- Original Message ----- 
From: "Corinna Vinschen" 
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, July 29, 2008 5:46 AM
Subject: Re: base-[files|password] for 1.7


| On Jul 28 14:55, Pierre A. Humblet wrote:
| > Looks like without argument the new mk{passwd/group} will dump the entire
| > passwd/group from the domain server. Some companies have tens of thousands
| > of names and that's why they weren't called with -l -d by default but with -l -c
| > 
| > The -c switch would only create an entry for the current user or the current primary group
| > WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
| > using only local info but mkgroup could not find the group name, so it was
| > calling it "mkgroup-l-d" .
| 
| I thought it's a good idea to have the domain by default.  It's a bit
| strange that a machine is running in a domain but as soon as another
| user logs in, the passwd and possibly group information for this user
| is missing.

Well yes, I don't recall what the complaints were about.
Perhaps long delays.
But it caused problems to NEW cygwin users installing for the first
time and without visibility or knowledge into what's happening.

| Even if we drop back to using mkpasswd -l -c, I don't think it makes
| sense to run mkgroup in a domain environment without fetching all
| domain groups.

Agreed, but it's done under user control.

| > The new mkgroup also has a -c option, which  gets the current primary
| > group name.  That's great, but does it contact the server? If so, how
| 
| No.  The -c options only open the user token and fetch the name
| information from a call to LookupAccountName(NULL, ...).  Since the
| user information for the current user is cached on the local machine,
| there's no server access.

Great. I am surprised we didn't do that before if it worked then.

| > does it behave when a domain user installs cygwin while not connected
| > to the domain server? That case generated complaints in the past.
| 
| Not for -c, but in the default case it will take some time until it
| times out and won't print the domain groups.  Since that's only an
| actual issue at installation time, where's the problem?

Not sure what the old complaints were about...
Do you expect the user and primary group to be put in passwd/group in that case?
 
| > I also noticed that the new mkpasswd -c does not put a guess about the full user name
| > in the comment field
| > old -c:
| > p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
| > new -c
| > p-humblet:unused:11068:11031: U-W...         <== no p-humblet
| > {old,new} -d
| > p-humblet:unused:11068:11031:Pierre Humblet,U-W...
| 
| Why do you need that?  

No idea why it was done like that in the first place :)
Does it work for domain users in absence of a server?

Pierre

Re: base-[files|password] for 1.7

[Corinna Vinschen]

On Jul 29 10:35, Pierre A. Humblet wrote:
> From: "Corinna Vinschen" 
> | I thought it's a good idea to have the domain by default.  It's a bit
> | strange that a machine is running in a domain but as soon as another
> | user logs in, the passwd and possibly group information for this user
> | is missing.
> 
> Well yes, I don't recall what the complaints were about.
> Perhaps long delays.
> But it caused problems to NEW cygwin users installing for the first
> time and without visibility or knowledge into what's happening.

That would have required a decision when to call mkpasswd -d in the
postinstall script.  I don't recall that we ever did that.

> |  I don't think it makes
> | sense to run mkgroup in a domain environment without fetching all
> | domain groups.
> 
> Agreed, but it's done under user control.

Just so that the group file doesn't get too big?

> | Not for -c, but in the default case it will take some time until it
> | times out and won't print the domain groups.  Since that's only an
> | actual issue at installation time, where's the problem?
> 
> Not sure what the old complaints were about...
> Do you expect the user and primary group to be put in passwd/group in that case?

I'm not sure I understand the question.  If we run mkpasswd/mkgroup
without arguments, you get local accounts on a non-domain machine
and domain accounts on a domain member machine.  Doesn't that make
the most sense?

> | > I also noticed that the new mkpasswd -c does not put a guess about the full user name
> | > in the comment field
> | > old -c:
> | > p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
> | > new -c
> | > p-humblet:unused:11068:11031: U-W...         <== no p-humblet
> | > {old,new} -d
> | > p-humblet:unused:11068:11031:Pierre Humblet,U-W...
> | 
> | Why do you need that?  
> 
> No idea why it was done like that in the first place :)
> Does it work for domain users in absence of a server?

No.  This information is only available from NetUserEnum/NetUserGetInfo
calls and those require DC access.


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

[Corinna Vinschen]

On Jul 29 10:31, Christopher Faylor wrote:
> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
> >Chris, is there any good reason NOT to call send_winch_maybe on
> >a key event?
> 
> It only makes sense when there is a mouse event.

I don't understand that.  Mouse events typically don't happen.  I can
use the mouse as much as I want in a console window running vim, vim
never gets the SIGWINCH.

>   It would make more
> sense to move the handling of SIGWINCH into the signal handler so that
> the above works transparently.  I'll look into doing that.

That would be a nice addition.


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

[John Morrison]

On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
> On Jul 29 10:31, Christopher Faylor wrote:
>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>> >Chris, is there any good reason NOT to call send_winch_maybe on
>> >a key event?
>>
>> It only makes sense when there is a mouse event.
>
> I don't understand that.  Mouse events typically don't happen.  I can
> use the mouse as much as I want in a console window running vim, vim
> never gets the SIGWINCH.
>
>>   It would make more
>> sense to move the handling of SIGWINCH into the signal handler so that
>> the above works transparently.  I'll look into doing that.
>
> That would be a nice addition.

So I don't need to add anything to /etc/profile?

J.

Re: base-[files|password] for 1.7

[Pierre A. Humblet]

----- Original Message ----- 
From: "Corinna Vinschen" <>
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, July 29, 2008 10:54 AM
Subject: Re: base-[files|password] for 1.7


| On Jul 29 10:35, Pierre A. Humblet wrote:
| > From: "Corinna Vinschen" 
| > | I thought it's a good idea to have the domain by default.  It's a bit
| > | strange that a machine is running in a domain but as soon as another
| > | user logs in, the passwd and possibly group information for this user
| > | is missing.
| > 
| > Well yes, I don't recall what the complaints were about.
| > Perhaps long delays.
| > But it caused problems to NEW cygwin users installing for the first
| > time and without visibility or knowledge into what's happening.
| 
| That would have required a decision when to call mkpasswd -d in the
| postinstall script.  I don't recall that we ever did that.

I don't recall the specifics but it would have been a lot easier to use
-d rather than to create a -c . There must have been a good reason.

| > |  I don't think it makes
| > | sense to run mkgroup in a domain environment without fetching all
| > | domain groups.
| > 
| > Agreed, but it's done under user control.
| 
| Just so that the group file doesn't get too big?

No, so that the user can ctrl-c if it takes forever.
 
| > | Not for -c, but in the default case it will take some time until it
| > | times out and won't print the domain groups.  Since that's only an
| > | actual issue at installation time, where's the problem?
| > 
| > Not sure what the old complaints were about...
| > Do you expect the user and primary group to be put in passwd/group in that case?
| 
| I'm not sure I understand the question.  If we run mkpasswd/mkgroup
| without arguments, you get local accounts on a non-domain machine
| and domain accounts on a domain member machine.  Doesn't that make
| the most sense?

It does make the most sense if all goes well and quickly. 
But if the server is not connected the passwd/group entries for the domain
user installing cygwin for the first time may not be created.

Pierre

Re: base-[files|password] for 1.7

[Christopher Faylor]

On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
>> On Jul 29 10:31, Christopher Faylor wrote:
>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>>> >Chris, is there any good reason NOT to call send_winch_maybe on
>>> >a key event?
>>>
>>> It only makes sense when there is a mouse event.
>>
>> I don't understand that.  Mouse events typically don't happen.  I can
>> use the mouse as much as I want in a console window running vim, vim
>> never gets the SIGWINCH.
>>
>>>   It would make more
>>> sense to move the handling of SIGWINCH into the signal handler so that
>>> the above works transparently.  I'll look into doing that.
>>
>> That would be a nice addition.
>
>So I don't need to add anything to /etc/profile?

Adding the kill -WINCH still makes sense.  It will at least get things
working for xterm and rxvt.

cgf

Re: base-[files|password] for 1.7

[Pierre A. Humblet]

----- Original Message ----- 
From: "Pierre A. Humblet" <>
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, July 29, 2008 12:24 PM
| ----- Original Message ----- 
| From: "Corinna Vinschen" <>
| To: <cygwin-apps@cygwin.com>
| Sent: Tuesday, July 29, 2008 10:54 AM
| || On Jul 29 10:35, Pierre A. Humblet wrote:
|| > From: "Corinna Vinschen" 
|| > | I thought it's a good idea to have the domain by default.  It's a bit
|| > | strange that a machine is running in a domain but as soon as another
|| > | user logs in, the passwd and possibly group information for this user
|| > | is missing.
|| > 
|| > Well yes, I don't recall what the complaints were about.
|| > Perhaps long delays.
|| > But it caused problems to NEW cygwin users installing for the first
|| > time and without visibility or knowledge into what's happening.
|| 
|| That would have required a decision when to call mkpasswd -d in the
|| postinstall script.  I don't recall that we ever did that.
| 
| I don't recall the specifics but it would have been a lot easier to use
| -d rather than to create a -c . There must have been a good reason.

I searched the list, there are tons of mails about mkpasswd, most from the
turn of the millennium, AFAICS. Here are two interesting ones:
http://www.cygwin.com/ml/cygwin/2001-10/msg01413.html
http://cygwin.com/ml/cygwin/2002-09/msg00663.html
The first one may well have been the trigger to have a -c switch.
The second gives you an example of what can happen, and this is not
acceptable under setup.

Pierre
 

Re: base-[files|password] for 1.7

[Christopher Faylor]

On Tue, Jul 29, 2008 at 01:59:54PM -0400, Christopher Faylor wrote:
>On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
>>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
>>> On Jul 29 10:31, Christopher Faylor wrote:
>>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>>>> >Chris, is there any good reason NOT to call send_winch_maybe on
>>>> >a key event?
>>>>
>>>> It only makes sense when there is a mouse event.
>>>
>>> I don't understand that.  Mouse events typically don't happen.  I can
>>> use the mouse as much as I want in a console window running vim, vim
>>> never gets the SIGWINCH.
>>>
>>>>   It would make more
>>>> sense to move the handling of SIGWINCH into the signal handler so that
>>>> the above works transparently.  I'll look into doing that.
>>>
>>> That would be a nice addition.
>>
>>So I don't need to add anything to /etc/profile?
>
>Adding the kill -WINCH still makes sense.  It will at least get things
>working for xterm and rxvt.

Ok.  I'm confused.  If I perform a "kill -SIGWINCH <pid>" on a bash
which is opened in a console window, the right number of lines shows up.
They also show up when you change the size of the window.

So it seems like this is working correctly without any Cygwin
modifications.

cgf

Re: base-[files|password] for 1.7

[Corinna Vinschen]

On Jul 29 18:21, Pierre A. Humblet wrote:
> From: "Pierre A. Humblet" <>
> | From: "Corinna Vinschen" <>
> || That would have required a decision when to call mkpasswd -d in the
> || postinstall script.  I don't recall that we ever did that.
> | 
> | I don't recall the specifics but it would have been a lot easier to use
> | -d rather than to create a -c . There must have been a good reason.
> 
> I searched the list, there are tons of mails about mkpasswd, most from the
> turn of the millennium, AFAICS. Here are two interesting ones:
> http://www.cygwin.com/ml/cygwin/2001-10/msg01413.html
> http://cygwin.com/ml/cygwin/2002-09/msg00663.html
> The first one may well have been the trigger to have a -c switch.
> The second gives you an example of what can happen, and this is not
> acceptable under setup.

John, scratch it.  Back to -l -c.  No change to base-passwd.  And I
really thought that this change would be helpful.  Bleah.  


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

[Corinna Vinschen]

On Jul 29 21:39, Christopher Faylor wrote:
> On Tue, Jul 29, 2008 at 01:59:54PM -0400, Christopher Faylor wrote:
> >On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
> >>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
> >>> On Jul 29 10:31, Christopher Faylor wrote:
> >>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
> >>>> >Chris, is there any good reason NOT to call send_winch_maybe on
> >>>> >a key event?
> >>>>
> >>>> It only makes sense when there is a mouse event.
> >>>
> >>> I don't understand that.  Mouse events typically don't happen.  I can
> >>> use the mouse as much as I want in a console window running vim, vim
> >>> never gets the SIGWINCH.
> >>>
> >>>>   It would make more
> >>>> sense to move the handling of SIGWINCH into the signal handler so that
> >>>> the above works transparently.  I'll look into doing that.
> >>>
> >>> That would be a nice addition.
> >>
> >>So I don't need to add anything to /etc/profile?
> >
> >Adding the kill -WINCH still makes sense.  It will at least get things
> >working for xterm and rxvt.
> 
> Ok.  I'm confused.  If I perform a "kill -SIGWINCH <pid>" on a bash
> which is opened in a console window, the right number of lines shows up.
> They also show up when you change the size of the window.
> 
> So it seems like this is working correctly without any Cygwin
> modifications.

Doesn't work for me.  kill -WINCH $$ creates the LINES and COLUMNS
values, but any later windows resize doesn't change the values.  And as
mentioned before it also doesn't work in vim.  Adding send_winch_maybe()
to the KEY_EVENT at least changes it at the next keypress.  And there's
no such thing as a mouse event, whatever I do with the mouse.


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

[Christopher Faylor]

On Wed, Jul 30, 2008 at 11:23:10AM +0200, Corinna Vinschen wrote:
>On Jul 29 21:39, Christopher Faylor wrote:
>> On Tue, Jul 29, 2008 at 01:59:54PM -0400, Christopher Faylor wrote:
>> >On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
>> >>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
>> >>> On Jul 29 10:31, Christopher Faylor wrote:
>> >>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>> >>>> >Chris, is there any good reason NOT to call send_winch_maybe on
>> >>>> >a key event?
>> >>>>
>> >>>> It only makes sense when there is a mouse event.
>> >>>
>> >>> I don't understand that.  Mouse events typically don't happen.  I can
>> >>> use the mouse as much as I want in a console window running vim, vim
>> >>> never gets the SIGWINCH.
>> >>>
>> >>>>   It would make more
>> >>>> sense to move the handling of SIGWINCH into the signal handler so that
>> >>>> the above works transparently.  I'll look into doing that.
>> >>>
>> >>> That would be a nice addition.
>> >>
>> >>So I don't need to add anything to /etc/profile?
>> >
>> >Adding the kill -WINCH still makes sense.  It will at least get things
>> >working for xterm and rxvt.
>> 
>> Ok.  I'm confused.  If I perform a "kill -SIGWINCH <pid>" on a bash
>> which is opened in a console window, the right number of lines shows up.
>> They also show up when you change the size of the window.
>> 
>> So it seems like this is working correctly without any Cygwin
>> modifications.
>
>Doesn't work for me.  kill -WINCH $$ creates the LINES and COLUMNS
>values, but any later windows resize doesn't change the values.  And as
>mentioned before it also doesn't work in vim.  Adding send_winch_maybe()
>to the KEY_EVENT at least changes it at the next keypress.  And there's
>no such thing as a mouse event, whatever I do with the mouse.

  L:\Documents and Settings\cgf>bash
  bash-3.2$ echo $LINES

  bash-3.2$ echo $LINES		# make window bigger
  42
  bash-3.2$ echo $LINES		# make window even bigger
  56

(also checked with a 4NT console)

Putting a "kill -WINCH $$" in my /home/cgf/.profile file causes LINES to
be set initially when I use "bash -login".

In my version of vim the screen size *does* change after every keypress
just like it always did.  I checked this with vim when I implemented it.

If this isn't working for you then fixing the symptom by checking on
every keystroke, slowing down the already slow input processing even
further, is not the correct first solution for handling the problem.

Cygwin does this:

SetConsoleMode (get_io_handle (), ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT);

If you are saying that this is broken in Windows or that it isn't being
properly set in Cygwin then that's what needs to be fixed.  Maybe
checking the screen size on every keystroke is the way to do it but,
since everything is working as I designed it for me, I am not yet
convinced.

cgf

Re: base-[files|password] for 1.7

[Corinna Vinschen]

On Jul 30 11:20, Christopher Faylor wrote:
> On Wed, Jul 30, 2008 at 11:23:10AM +0200, Corinna Vinschen wrote:
> >On Jul 29 21:39, Christopher Faylor wrote:
> >> Ok.  I'm confused.  If I perform a "kill -SIGWINCH <pid>" on a bash
> >> which is opened in a console window, the right number of lines shows up.
> >> They also show up when you change the size of the window.
> >> 
> >> So it seems like this is working correctly without any Cygwin
> >> modifications.
> >
> >Doesn't work for me.  kill -WINCH $$ creates the LINES and COLUMNS
> >values, but any later windows resize doesn't change the values.  And as
> >mentioned before it also doesn't work in vim.  Adding send_winch_maybe()
> >to the KEY_EVENT at least changes it at the next keypress.  And there's
> >no such thing as a mouse event, whatever I do with the mouse.
> 
>   L:\Documents and Settings\cgf>bash
>   bash-3.2$ echo $LINES
> 
>   bash-3.2$ echo $LINES		# make window bigger
>   42
>   bash-3.2$ echo $LINES		# make window even bigger
>   56
> 
> (also checked with a 4NT console)

In a standard console window on Windows 2008 (but the OS doesn't matter):

  $ echo $LINES

  $ echo $LINES				# make windows smaller

  $ echo $LINES				# make windows bigger

  $ kill -WINCH $$; echo $LINES
  54
  $ echo $LINES				# make windows smaller
  54

> Putting a "kill -WINCH $$" in my /home/cgf/.profile file causes LINES to
> be set initially when I use "bash -login".
> 
> In my version of vim the screen size *does* change after every keypress
> just like it always did.  I checked this with vim when I implemented it.

It never worked right for me in a console window.

> If this isn't working for you then fixing the symptom by checking on
> every keystroke, slowing down the already slow input processing even
> further, is not the correct first solution for handling the problem.

I didn't claim that.  I just mentioned that to point out the difference.

> SetConsoleMode (get_io_handle (), ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT);

I know.  I have no idea what could be different between your and my
setup, though.


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

[Yaakov (Cygwin Ports)]

-----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

[Corinna Vinschen]

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

[Yaakov (Cygwin Ports)]

-----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

[Corinna Vinschen]

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

[Charles Wilson]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Yaakov (Cygwin Ports)]

-----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

[Corinna Vinschen]

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

[Corinna Vinschen]

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