Problems on case-sensitive file systems
I'm facing a number of issues with case-sensitivity which I've collected: There is a documented limitation on case-sensitivity using drive letter paths, also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html (last item). I vaguely remember seeing a reason for this limitation in some mail but can't find it again. I think it would be good to remove this limitation because it breaks user expectations when working on case-sensitive drives. Note I'm not asking about EXFAT (as in that thread) but using Windows or mixed paths on NTFS or network drives, which should be easy to transform/normalize for access. According to documentation, the posix mount flag is enforced to be the same for all mounts below /cygdrive; is there a strong reason? I think this is not useful, because you may likely want data drives to be case-sensitive but it's not good for the Windows system drive (because Windows is so silly to have something like C:\WINDOWS\system32 in the path while the names are C:\Windows\System32... as a workaround, I once set a symbolic link into C:\ - ln -s WINDOWS Windows. This worked nicely until I wanted to reboot and it didn't find it's system folder anymore :( ). To achieve the desired mount, I tried this: D: /drives/d ntfs binary,nouser,posix=1,noumount but somehow it does not seem to work for local drives while it works nicely for network drives. mv XY xy does not work if XY is a directory (no effect, no message) If I switch Windows to case-sensitivity, there is no .EXE magic (only .exe magic). So e.g. PING: command not found, while PING.EXE works. Well, there are only a few .EXE files around, so this may be acceptable. -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Question about porting eCAP
Hi.
Recently, I want run squid with eCAP feature on windows.
Now, I have compiled eCAP-0.2.0 on cygwin. As a result, I some files as follow.
--eCAP-
DDD@DDD-PC /usr/local/lib
$ ls
libecap.a libecap.la pkgconfig
DDD@DDD-PC /usr/local/lib
$ cd pkgconfig/
DDD@DDD-PC /usr/local/lib/pkgconfig
$ ls
libecap.pc
HDM@HDM-PC /usr/local/lib/pkgconfig
$
--eCAP end-
Then, I compiled squid-3.3.3-2 with --enable-ecap option successfuly
on cygwin by editing squid.cygport.
squid.cygport--
src_compile() {
cd ${S}
./bootstrap.sh
lndirs
cd ${B}
cygconf \
--sysconfdir=/etc/squid \
--datadir=/usr/share/squid \
--libexecdir=/usr/lib/squid \
--disable-strict-error-checking \
--with-logdir=/var/log/squid \
--with-swapdir=/var/cache/squid \
--with-pidfile=/var/run/squid.pid \
--enable-ecap \ # Here. --enable-ecap option is
--enable-ssl \
--enable-esi \
--enable-disk-io="AIO,Blocking,DiskThreads,IpcIo,Mmapped" \
--enable-auth-basic="DB,LDAP,MSNT,MSNT-multi-domain,NCSA,POP3,RADIUS,SASL,SMB,fake,getpwnam"
\
--enable-auth-ntlm='fake,smb_lm' \
--enable-auth-negotiate='kerberos,wrapper' \
--enable-external-acl-helpers='LDAP_group,SQL_session,eDirectory_userip,file_userip,kerberos_ldap_group,session,time_quota,unix_group,wbinfo_group'
\
squid.cygport end--
But, when I compile ecap-adapter sample, I just get some files as following.
---ecap-adapter sample
HDM@HDM-PC /usr/local/lib
$ ls
ecap_adapter_minimal.a ecap_adapter_minimal.la
ecap_adapter_modifying.a ecap_adapter_modifying.la
ecap_adapter_passthru.a ecap_adapter_passthru.la libecap.a libecap.la
libecap.so.2.0.0 pkgconfig
---ecap-adapter sample
end
Of couse, Squid can't load it. When I configure Squid to load it, I
just these error message.
--Squid error message
-
$ ./squid.exe -N -C -d1
2014/10/20 23:33:26| WARNING cache_mem is larger than total disk cache space!
2014/10/20 23:33:26| Starting Squid Cache version 3.3.3 for i686-pc-cygwin...
2014/10/20 23:33:26| Process ID 3200
2014/10/20 23:33:26| Process Roles: master worker
2014/10/20 23:33:26| With 3072 file descriptors available
2014/10/20 23:33:26| Initializing IP Cache...
2014/10/20 23:33:26| DNS Socket created at [::], FD 4
2014/10/20 23:33:26| DNS Socket created at 0.0.0.0, FD 5
2014/10/20 23:33:26| Adding nameserver 8.8.8.8 from squid.conf
2014/10/20 23:33:26| Logfile: opening log daemon:/var/log/squid/access.log
2014/10/20 23:33:26| Logfile Daemon: opening log /var/log/squid/access.log
2014/10/20 23:33:26| WARNING: no_suid: setuid(0): (22) Invalid argument
2014/10/20 23:33:26| WARNING: no_suid: setuid(0): (22) Invalid argument
2014/10/20 23:33:27| Unlinkd pipe opened on FD 11
2014/10/20 23:33:27| Store logging disabled
2014/10/20 23:33:27| Swap maxSize 102400 + 262144 KB, estimated 28041 objects
2014/10/20 23:33:27| Target number of buckets: 1402
2014/10/20 23:33:27| Using 8192 Store buckets
2014/10/20 23:33:27| Max Mem size: 262144 KB
2014/10/20 23:33:27| Max Swap size: 102400 KB
2014/10/20 23:33:27| Rebuilding storage in /var/cache/squid (dirty log)
2014/10/20 23:33:27| Using Least Load store dir selection
2014/10/20 23:33:27| Set Current Directory to /var/cache/squid
2014/10/20 23:33:27| Loaded Icons.
2014/10/20 23:33:27| HTCP Disabled.
2014/10/20 23:33:27| Loading Squid module from
'/usr/local/lib/ecap_adapter_modifying.so'
2014/10/20 23:33:27| FATAL: dying from an unhandled exception: %1 is
not a valid Win32 application.
terminate called after throwing an instance of 'TextException'
what(): %1 is not a valid Win32 application.
Aborted (core dumped)
--Squid error
message---
There are some output message when I compile ecap-adapter sample.
--output message
Making all in src
make[1]: Entering directory '/usr/src/ecap_adapter_sample-0.2.1/src'
make all-am
make[2]: Entering directory '/usr/src/ecap_adapter_sample-0.2.1/src'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I../src -I/usr/local/include -g -O3 -Wall -Wwrite-strings
-Woverloaded-virtual -pipe -MT adapter_minimal.lo -MD -MP -MF
.deps/adapter_minimal.Tpo -c -o adapter_minimal.lo adapter_minimal.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I../src -I/usr/local/include -g
-O3 -Wall -Wwrite-strings -Woverloaded-virtual -pipe -MT
adapter_minimal.lo -MD -MP -MF .deps/adapter_minimal.Tpo -c
adapter_minimal.cc -DDLL_EXPORT -DPIC -o .libs/adapter_minimal.o
libtool: compile: g++ -DHAVE_CONFIG_H -I../src -I/usr/local/include -g
-O3 -Wall -Wwrite-strings -Woverloaded-virtual -pipe -MT
adapter_minimal.lo -MD -MP -MF .deps/adapter
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Hi Cygwin friends and users, I just released a TEST version of the next upcoming Cygwin release, 1.7.33-0.1. If you want to help testing this new release (which I seriously hope for), you can find it in your setup-x86.exe or setup-x86_64.exe as "test" release. The major change in this new release is the new method to read account (passwd and group) information from the Windows user databases directly, without the requirement to generate /etc/passwd and /etc/group files to generate Unix-like uid and gid. For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html If you read it (which I seriously hope for) and it's all just incomprehensible gobbledygook to you, please say so on the mailing list cygwin AT cygwin DOT com so we have a chance to improve the documentation. Please give this TEST release a try. If you find problems in the new features or regressions compared to the current stable release 1.7.32, please report them to the public mailing list cygwin AT cygwin DOT com Following is a list of changes in this new release: What's new: --- - Cygwin can now generate passwd/group entries directly from Windows user databases (local SAM or Active Directory), thus allowing to run Cygwin without having to create /etc/passwd and /etc/group files. Introduce /etc/nsswitch.conf file to configure passwd/group handling. For bordercase which require to use /etc/passwd and /etc/group files, change mkpasswd/mkgroup to generate passwd/group entries compatible with the entries read from SAM/AD. - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix. This can be utilized in scripts to access paths via cygdrive prefix, even if the cygdrive prefix has been changed by the user. - /proc/partitions now prints the windows mount points the device is mounted on. This allows to recognize the underlying Windows devices of the Cygwin raw device names. - New API: quotactl, designed after the Linux/BSD function, but severly restricted: Windows only supports user block quotas on NTFS, no group quotas, no inode quotas, no time constraints. - New APIs: ffsl, ffsll (glibc extensions). What changed: - - New internal exception handling based on SEH on 64 bit Cygwin. - Revamp Solaris ACL implementation to more closely work like POSIX ACLs are supposed to work. Finally implement a CLASS_OBJ emulation. Update getfacl(1)/setfacl(1) accordingly. - Drop the current working directory from the default DLL search path in favor of Cygwin's /bin dir. - Improve various header files for C++- and standards-compliance. - Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6. Bug Fixes - - Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid directory stream. - Fix a resource leak in rmdir(2). - Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after open and before calling one of the affected functions. Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html - Handle Netapp-specific problem in statvfs(2)/fstatvfs(2). Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html - Fix chown(2) on ptys in a corner case. - Generate correct error when a path is inaccessible due to missing permissions. Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html - Don't hang in accept calls if socket is no listener. Set errno to EINVAL instead. Don't hang in read/recv/recvfrom/recvmsg calls if socket is connection oriented and not connected. Set errno to ENOTCONN instead. - Don't allow seeking on serial lines and sockets. Set errno to ESPIPE instead. Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html - Fix output of /proc//statm. - Fix a SEGV in cygcheck if the environment variable COMSPEC is not, or incorrectly set. Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00292.html To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Corinna Vinschen wrote:
The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.
Does it mean that the users with /etc/{passwd,group} files have to
rename them [*] before its installation TO TEST the new functionality?
Thanks,
Angelo.
---
E.g. : "mv /etc/{passwd, group} /etc/{passwd-save, group-save}"
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 22 14:07, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> >The major change in this new release is the new method to read account
> >(passwd and group) information from the Windows user databases directly,
> >without the requirement to generate /etc/passwd and /etc/group files to
> >generate Unix-like uid and gid.
>
> Does it mean that the users with /etc/{passwd,group} files have to rename
> them [*] before its installation TO TEST the new functionality?
By default, Cygwin will use the file content, and fallback to requesting
account info from Windows if an account is missing in pasdswd or group.
As an example, just try `id':
$ id
uid=1049577(corinna) gid=1049701(vinschen)
groups=1049701(vinschen),545(Users),14(REMOTE INTERACTIVE
LOGON),4(INTERACTIVE),11(Authenticated Users),15(This
Organization),4095(CurrentSession),66048(LOCAL),1049713(hirmke),1049089(Domain
Users),1049148(Denied RODC Password Replication Group),401408(Medium Mandatory
Level)
Remoing the files is one way to test, but it's the more awkward one.
The better way is to create an /etc/nsswitch.conf file with the
following content, and then stop your Cygwin shell and restart it:
$ cat > /etc/nsswitch.conf
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Corinna Vinschen wrote: As an example, just try `id': $ id uid=1049577(corinna) gid=1049701(vinschen) groups=1049701(vinschen),545(Users), Here it prints: uid=197609(angelo) gid=197121(None) gruppi=197121(None), 197608(HomeUsers), 545(Users), and many files are listed ad "angelo None", -rw-r--r-- 1 angelo None 8222906 22 set 16.12 14-007r2.pdf -rw-r--r-- 1 angelo None 354744 15 ott 13.43 ... in your case, if I understand, you should have something like this -rw-r--r-- 1 corinna vinschen 8222906 22 set 16.12 14-007r2.pdf -rw-r--r-- 1 corinna vinschen 354744 15 ott 13.43 ... instead... more interesting.. For the details, see the new documentation, please. yes, it will take a bit of time (mainly to understand... ;-)) Ciao and thanks, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Read through https://cygwin.com/preliminary-ntsec.html and in general found it to be quite useful. I'm hoping to do some testing perhaps later this week or early next. I have a couple of questions: 1) Any thoughts about the rough timing of this "going live"? 2) The documentation says (as I read it): Well-known/builtin accounts named as in Windows, then (for domain member) "Local machine accounts of a domain member machine get a Cygwin user name the same way as accounts from another domain: The local machine name gets prepended". As I read this, cyg_serv account (under which I currently run SSHD) would now have a new name MYMACHINE+cyg_serv. Am I reading this correctly? Is there some reconfiguration I'll need to do to get SSHD to run properly? 3) I also read "Cygwin implements the Solaris API to access Windows ACLs in a Unixy way" (although your email says "Revamp Solaris ACL implementation to more closely work like POSIX ACLs are supposed to work"). So is it Solaris or is it POSIX, and if Solaris then I wonder why since it seems that everywhere else you've tried to be as POSIX as possible. Thanks for all your hard work on this, I will certainly be one of the benefactors (12 Mb group file, takes hours to refresh so not done since this time last year). Dave
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 22 15:27, Angelo Graziosi wrote: > Corinna Vinschen wrote: > >As an example, just try `id': > > > >$ id > >uid=1049577(corinna) gid=1049701(vinschen) > >groups=1049701(vinschen),545(Users), > > Here it prints: > > uid=197609(angelo) gid=197121(None) gruppi=197121(None), 197608(HomeUsers), > 545(Users), > > and many files are listed ad "angelo None", > > -rw-r--r-- 1 angelo None 8222906 22 set 16.12 14-007r2.pdf > -rw-r--r-- 1 angelo None 354744 15 ott 13.43 ... Correct. "None" is the name of the default group of local, non-domain accounts on Windows. This should be documented in the new documentation as well, including the "how to tweak". > in your case, if I understand, you should have something like this > > -rw-r--r-- 1 corinna vinschen 8222906 22 set 16.12 14-007r2.pdf > -rw-r--r-- 1 corinna vinschen 354744 15 ott 13.43 ... > > instead... more interesting.. > > >For the details, see the new documentation, please. > > yes, it will take a bit of time (mainly to understand... ;-)) Agreed. Windows account handling and security stuff isn't easy anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgplWVLc64TZS.pgp Description: PGP signature
Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Greetings, John Wiersba! > I'm trying to use run.exe to avoid a flashing console window, but it is not > working on my cygwin64 install on Win7Pro-64. This is a fresh install from > 10/20/2014. I've attached my cygcheck.out. I've tried the following > windows shortcuts and all cause a console window to briefly flash (in the > case of mintty a console window flashes before the mintty terminal is > displayed). > D:\cygwin\bin\run.exe /bin/bash -c "echo hi" > D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi" > D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc > Since hiding the console window is the main purpose of run.exe, it seems > that it is badly broken for Win7Pro-64. Can you tell, what is that console? I.e. what's in it's header? -- WBR, Andrey Repin (anrdae...@yandex.ru) 22.10.2014, <17:35> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems on case-sensitive file systems
On 10/22/2014 01:01 AM, Thomas Wolff wrote: > > mv XY xy does not work if XY is a directory (no effect, no message) Might be something I can fix (I already have cygwin-local patches to allow 'mv A.txt a.txt', so it is probably just incomplete if directories aren't working). > > If I switch Windows to case-sensitivity, there is no .EXE magic (only > .exe magic). > So e.g. PING: command not found, while PING.EXE works. I know the .exe magic I added in coreutils tries to be case insensitive, but I don't know if cygwin1.dll does the same; in the case of exec'ing a program, that's the cygwin1.dll choosing whether to try all possible cases. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 22 13:35, Habermann, Dave (DA) wrote: > Read through https://cygwin.com/preliminary-ntsec.html and in general > found it to be quite useful. I'm hoping to do some testing perhaps > later this week or early next. I have a couple of questions: > > 1) Any thoughts about the rough timing of this "going live"? I'm heading for "at some arbitrary day in November". > 2) The documentation says (as I read it): Well-known/builtin accounts > named as in Windows, then (for domain member) "Local machine accounts > of a domain member machine get a Cygwin user name the same way as > accounts from another domain: The local machine name gets prepended". > As I read this, cyg_serv account (under which I currently run SSHD) > would now have a new name MYMACHINE+cyg_serv. Am I reading this > correctly? Is there some reconfiguration I'll need to do to get SSHD > to run properly? In theory, no. The last OpenSSH update, 6.7p1-1, alreadyd contained the upstream fix to work with local sshd accounts which have the machine name prepended. > 3) I also read "Cygwin implements the Solaris API to access Windows > ACLs in a Unixy way" (although your email says "Revamp Solaris ACL > implementation to more closely work like POSIX ACLs are supposed to > work"). So is it Solaris or is it POSIX, and if Solaris then I wonder > why since it seems that everywhere else you've tried to be as POSIX as > possible. Solaris ACLs *are* POSIX ACLs :) The difference is not how these ACLs look like, but only in the API used to access the ACLs. The Solaris API was finished and working at the time I implemented this POSIX ACL support in Cygwin, while the POSIX draft 1003.1e was still in the works, and our role model Linux didn't even now how to spell ACL. These days, Linux implements the POSIX 1003.1e draft, (which, funny enough, has been withdrawn long ago), while Solaris and Cygwin provide the original Solaris API. What has chnaged with 1.7.33 is that the handling of POSIX ACLs is now much more aligned with how they are implemented on Solaris or Linux. Especially the CLASS_OBJ stuff didn't exist before, but now it gets emulated. > Thanks for all your hard work on this, I will certainly be one of the > benefactors (12 Mb group file, takes hours to refresh so not done > since this time last year). Cool, thank you! I'm really looking forward to this release. The account handling changes is something I had on the TODO list for ages, and the new SEH-based internal exception handling is a great benefit for the 64 bit version. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpOylelf1HOW.pgp Description: PGP signature
Re: Problems on case-sensitive file systems
On Oct 22 07:52, Eric Blake wrote: > On 10/22/2014 01:01 AM, Thomas Wolff wrote: > > > > > mv XY xy does not work if XY is a directory (no effect, no message) > > Might be something I can fix (I already have cygwin-local patches to > allow 'mv A.txt a.txt', so it is probably just incomplete if directories > aren't working). > > > > > If I switch Windows to case-sensitivity, there is no .EXE magic (only > > .exe magic). > > So e.g. PING: command not found, while PING.EXE works. > > I know the .exe magic I added in coreutils tries to be case insensitive, > but I don't know if cygwin1.dll does the same; in the case of exec'ing a > program, that's the cygwin1.dll choosing whether to try all possible cases. Cygwin only recognizes lowercase .exe and .dll in casesensitive mode. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGi0CLOD4gk.pgp Description: PGP signature
Re: Problems on case-sensitive file systems
On Oct 22 09:01, Thomas Wolff wrote: > I'm facing a number of issues with case-sensitivity which I've collected: > > There is a documented limitation on case-sensitivity using drive letter > paths, > also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html > (last item). I vaguely remember seeing a reason for this limitation in some > mail but can't find it again. I think it would be good to remove this > limitation because it breaks user expectations when working on > case-sensitive drives. The user expectation when using DOS paths is caseinsensitivity in the first place. But, as usual, there's no way to do this right, since somebody will have another POV. My stance is, don't use DOS paths when using Cygwin. At leats don't use DOS paths if you have any expectations about special POSIX path handling on Cygwin. > According to documentation, the posix mount flag is enforced to be the same > for all mounts below /cygdrive; is there a strong reason? Yes. The flags are shared between all cygdrive paths. If you need something else, don;'t use the cygdrive path, but another, manually added mount point. Note that this: none /cygdrive cygdrive binary,posix=0,user 0 0 D: /cygdrive/d ntfs binary,nouser,posix=1,noumount 0 0 does NOT work. The manual paths must not overlap with the cygdrive paths. Use somehthing else instead: D: /drive_d ntfs binary,nouser,posix=1,noumount 0 0 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpv8n9eKpB5N.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 22 15:54, Corinna Vinschen wrote: > On Oct 22 13:35, Habermann, Dave (DA) wrote: > > 3) I also read "Cygwin implements the Solaris API to access Windows > > ACLs in a Unixy way" (although your email says "Revamp Solaris ACL > > implementation to more closely work like POSIX ACLs are supposed to > > work"). So is it Solaris or is it POSIX, and if Solaris then I wonder > > why since it seems that everywhere else you've tried to be as POSIX as > > possible. > > Solaris ACLs *are* POSIX ACLs :) > > The difference is not how these ACLs look like, but only in the API > used to access the ACLs. > > The Solaris API was finished and working at the time I implemented this > POSIX ACL support in Cygwin, while the POSIX draft 1003.1e was still in > the works, and our role model Linux didn't even now how to spell ACL. > These days, Linux implements the POSIX 1003.1e draft, (which, funny > enough, has been withdrawn long ago), while Solaris and Cygwin provide > the original Solaris API. Btw., this probably goes without saying, but I would be really grateful if somebody wants to take a stab at implementing the POSIX API, maybe just on top of the underlying Solaris API, maybe as separate libacl.a as on Linux. One may dream... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXY3prSjrSu.pgp Description: PGP signature
Re: perl -d causes completion to fail
On Mon, Oct 20, 2014 at 02:04:18PM -0700, Andrew DeFaria wrote: > On 10/20/2014 1:05 PM, Ken Brown wrote: > >On 10/20/2014 1:04 PM, Andrew DeFaria wrote: > >>On 10/20/2014 4:23 AM, Adam Dinwoodie wrote: > >>>Whatever you're using doesn't seem to be the Cygwin bash-completion > >>>package. Both x86 and x86_64 install /etc/bash_completion.d/perl: > >>> > >>>https://cygwin.com/packages/x86/bash-completion/bash-completion-1.3-1 > >>>https://cygwin.com/packages/x86_64/bash-completion/bash-completion-1.3-1 > >>> > >>>Before we go any further with anything else, I think your next step > >>>should probably be to install the Cygwin bash-completion package and > >>>check what the behaviour is there. > >> > >>I ran setup and I see a "Keep" for 2.1-1 of bash-completion. I believe > >>that means it's already installed. > > > >It means you installed it from some source (Cygwin Ports maybe?) other > >than a Cygwin mirror. As Adam said, Cygwin provides version 1.3-1. > > I've never installed any Cygwin stuff from anything other than > setup.exe. The Cygwin mirror I typically use is > http://mirrors.kernal.org. Oddly enough, looking at it now, I see > Current as 2.1-1 and "new" as 1.3-1. Huh? OK... Installing "new"... Cygwin Ports uses setup-*.exe for installing its packages. It's also currently distributing bash-completion 2.1-1, so I strongly suspect that at some point -- intentionally or not -- you installed the Cygwin Ports version. Incidentally, almost everything in this mail trail so far could have been skipped if you'd included `cygcheck -srv` output in your initial email, as we'd have been able to tell straight away that you weren't using the official Cygwin version of bash-completion. > Well now I do have 1.3-1 and I have an /etc/bash_completion.d/perl, > but it behaves the same... :-( The next step I'd suggest is to check if the upstream bash-completion package has the behaviour you're looking for. If upstream does have this behaviour, you can (a) install it yourself, separately from the Cygwin install (but be aware the list won't support problems you hit unless/until you can identify the Cygwin-distributed component that's causing the problem), and/or (b) request the Cygwin bash-completion maintainer upgrade to a more recent version. If upstream doesn't have this behaviour, I can see a bunch of options: a) Write a plugin yourself to do it. The obvious place to put this would be ~/.bash_completion, which is automatically included by the bash_completion scripts if it exists. Optionally submit it upstream then follow all the previous instructions about getting it included in Cygwin. b) Find the mailing list/equivalent for upstream and ask them to add the feature. See above if they actually do so. c) Find a third-party plugin that provides this feature. Install it manually or ITP it and have it included in Cygwin properly. d) Live without it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Fwd: keychain 2.7.1 and fish-2.1.1-3 incompatibility
The current Cygwin version of keychain (2.7.1) apparently requires a patch to use alongside newer versions of the FISH shell. This was already fixed upstream: https://github.com/funtoo/keychain/commit/b73fc50ba27fb5f62864ee097f9d118ac6e0fba6 This patch was included in the keychain 2.7.2_beta1 version available on their mirrors. I've been using this patched version on Cygwin and it works. Could someone push a fixed version out this out? Thanks, Kelley Cook -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: keychain 2.7.1 and fish-2.1.1-3 incompatibility
> The current Cygwin version of keychain (2.7.1) apparently requires a > patch to use alongside newer versions of the FISH shell. > > This was already fixed upstream: > > https://github.com/funtoo/keychain/commit/b73fc50ba27fb5f62864ee097f9d118ac6e0fba6 > > This patch was included in the keychain 2.7.2_beta1 version available > on their mirrors. I've been using this patched version on Cygwin and > it works. FWIW, I didn't know this was being worked on upstream. I just worked around it by running if not ssh-add -l >&- set SSH_AUTH_SOCK set SSH_AGENT_PID keychain --eval $keys | source end Until a new keychain comes out, the above should serve as a workaround. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Corinna Vinschen writes: > In theory, no. The last OpenSSH update, 6.7p1-1, alreadyd contained > the upstream fix to work with local sshd accounts which have the > machine name prepended. I will check this tomorrow, I somehow missed that this patch was live. The entry for sshd was the only thing still in my servers' /etc/passwd. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl -d causes completion to fail
On 10/22/2014 7:50 AM, Adam Dinwoodie wrote: I've never installed any Cygwin stuff from anything other than setup.exe. The Cygwin mirror I typically use is http://mirrors.kernal.org. Oddly enough, looking at it now, I see Current as 2.1-1 and "new" as 1.3-1. Huh? OK... Installing "new"... Cygwin Ports uses setup-*.exe for installing its packages. It's also currently distributing bash-completion 2.1-1, so I strongly suspect that at some point -- intentionally or not -- you installed the Cygwin Ports version. If I did it was totally unintentional especially considering I don't know what a Cygwin Ports is though I imagine it about porting open source software to Cygwin and perhaps maybe a site. Are you telling me that http://mirrors.kernal.org is a "Cygwin Ports" site? Ah dang! You're right! I recalled that setup asks for a local package dir and I typically keep a Cygwin folder with all of the stuff I use downloaded in case anybody else wants to use it locally. I recalled how it has directories under it with encoded URL names so I decided to check my "repo" and lo and behold there's a ftp%3a%2f%2fftp.cygwinports.org%2fpub%2fcygwinports%2f directory there. I had no idea that this "Ports" URL was different than any other URL in that list... OK so is this bad? Should I remove it? How would I "back this out"? Incidentally, almost everything in this mail trail so far could have been skipped if you'd included `cygcheck -srv` output in your initial email, as we'd have been able to tell straight away that you weren't using the official Cygwin version of bash-completion. Well now I do have 1.3-1 and I have an /etc/bash_completion.d/perl, but it behaves the same... :-( The next step I'd suggest is to check if the upstream bash-completion package has the behaviour you're looking for. If upstream does have this behaviour, you can (a) install it yourself, separately from the Cygwin install (but be aware the list won't support problems you hit unless/until you can identify the Cygwin-distributed component that's causing the problem), and/or (b) request the Cygwin bash-completion maintainer upgrade to a more recent version. If upstream doesn't have this behaviour, I can see a bunch of options: a) Write a plugin yourself to do it. The obvious place to put this would be ~/.bash_completion, which is automatically included by the bash_completion scripts if it exists. Optionally submit it upstream then follow all the previous instructions about getting it included in Cygwin. Wow! I didn't know that bash_completion sourced ~/.bash_completion. That's good to know as I have written my own bash_completions - an extensive set that covers just about all of the Clearcase commands complete with smarts to complete Clearcase objects like labels, branch names, etc. Contact me if you want a copy. b) Find the mailing list/equivalent for upstream and ask them to add the feature. See above if they actually do so. c) Find a third-party plugin that provides this feature. Install it manually or ITP it and have it included in Cygwin properly. d) Live without it. Quite honestly option D is the best choice for me at this moment as this is the only thing that doesn't complete for me and I'm about to be hammered at work and too busy to follow up on this. Maybe later. Damn good response though! Thanks. -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl -d causes completion to fail
On 10/22/2014 08:50 AM, Adam Dinwoodie wrote: > > If upstream does have this behaviour, you can (a) install it yourself, > separately from the Cygwin install (but be aware the list won't support > problems you hit unless/until you can identify the Cygwin-distributed > component that's causing the problem), and/or (b) request the Cygwin > bash-completion maintainer upgrade to a more recent version. At any rate, the bash-completion maintainer (me) is already aware that I am overdue on packaging the latest upstream release, so it should be hitting cygwin.com as my next package build, hopefully within the next week... -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: perl -d causes completion to fail
On 10/22/2014 1:09 PM, Andrew DeFaria wrote: On 10/22/2014 7:50 AM, Adam Dinwoodie wrote: Cygwin Ports uses setup-*.exe for installing its packages. It's also currently distributing bash-completion 2.1-1, so I strongly suspect that at some point -- intentionally or not -- you installed the Cygwin Ports version. If I did it was totally unintentional especially considering I don't know what a Cygwin Ports is though I imagine it about porting open source software to Cygwin and perhaps maybe a site. Are you telling me that http://mirrors.kernal.org is a "Cygwin Ports" site? No. This is what Cygwin Ports is: https://sourceware.org/cygwinports/ Ah dang! You're right! I recalled that setup asks for a local package dir and I typically keep a Cygwin folder with all of the stuff I use downloaded in case anybody else wants to use it locally. I recalled how it has directories under it with encoded URL names so I decided to check my "repo" and lo and behold there's a ftp%3a%2f%2fftp.cygwinports.org%2fpub%2fcygwinports%2f directory there. I had no idea that this "Ports" URL was different than any other URL in that list... OK so is this bad? Should I remove it? How would I "back this out"? Just remove it. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Andrey, the flashing console flashes very quickly and I don't know how to slow it down. It appears to have no title and no contents. I gave up on using the bash option -c, because of clashes due to mixing windows and linux command line parsing conventions. So, instead I created a script /d/try: export PATH=/bin sleep 10 date >>/d/out.txt # cygdrive is / Here are the results of my recent tests: When I run: D:\cygwin\bin\run.exe /bin/bash --norc /d/try then there is a flashing console window which closes immediately. It appears to have no title or contents but it's hard to tell since it flashes so quickly. In the process list of Process Explorer (from Microsoft's SysInternals), I can see: 1) conhost.exe "Console Window Host" (nested under csrss.exe "Client Server Runtime Process")) 2) bash.exe (at the top level) 3) sleep.exe (at the top level) After the expected 10 seconds, the processes disappear and the file /d/out.txt gets written to. If I run instead: D:\cygwin\bin\bash.exe --norc /d/try I get an empty console window (which doesn't close immediately), with the same title as my shortcut name. This console window closes after the specified 10 seconds. In this case, there is a slight change in the processes running: 1) conhost.exe "Console Window Host" (nested under csrss.exe "Client Server Runtime Process")) 2) bash.exe (running under explorer.exe "Windows Explorer") 3) sleep.exe (at the top level) So, definitely, run.exe is *not* preventing the flashing console window as I expected it to. > > From: Andrey Repin >To: John Wiersba ; cygwin@cygwin.com >Sent: Wednesday, October 22, 2014 9:36 AM >Subject: Re: run.exe flashes non-hidden console window in cygwin64 on >Win7Pro-64 > > >Greetings, John Wiersba! > > >> I'm trying to use run.exe to avoid a flashing console window, but it is not >> working on my cygwin64 install on Win7Pro-64. This is a fresh install from >> 10/20/2014. I've attached my cygcheck.out. I've tried the following >> windows shortcuts and all cause a console window to briefly flash (in the >> case of mintty a console window flashes before the mintty terminal is >> displayed). > >> D:\cygwin\bin\run.exe /bin/bash -c "echo hi" >> D:\cygwin\bin\run.exe /bin/env -i PATH=/bin bash --norc -c "echo hi" >> D:\cygwin\bin\run.exe /bin/env -i PATH=/bin mintty bash --norc > > >> Since hiding the console window is the main purpose of run.exe, it seems >> that it is badly broken for Win7Pro-64. > >Can you tell, what is that console? I.e. what's in it's header? > > >-- >WBR, >Andrey Repin (anrdae...@yandex.ru) 22.10.2014, <17:35> > >Sorry for my terrible english... > > >-- >Problem reports: http://cygwin.com/problems.html >FAQ: http://cygwin.com/faq/ >Documentation:http://cygwin.com/docs.html >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > > > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
On 22 October 2014 14:34, John Wiersba wrote: > Andrey, the flashing console flashes very quickly and I don't know how to > slow it down. > It appears to have no title and no contents. run appears to work correctly when you use it at a cygwin shell prompt. run.exe is a cygwin executable; use ldd see the DLLs that it uses. Since your shortcut is not starting a windows GUI program, it starts a console window, possibly executing cmd.exe It is this console windows where cmd.exe executes run.exe that you see flashing on the screen. Have you tried changing the shortcut to cause it to open the window minimized? I vaguely remember doing something like that with the cygwin.bat clone I used to start a (non-X windows) rxvt window. Doug -- Doug Henderson, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run.exe flashes non-hidden console window in cygwin64 on Win7Pro-64
Greetings, Doug Henderson! >> Andrey, the flashing console flashes very quickly and I don't know how to >> slow it down. >> It appears to have no title and no contents. Normally, I just fire up a screen recorder in such cases. But I seems to have missed the beginning of a discussion. > run appears to work correctly when you use it at a cygwin shell prompt. > run.exe is a cygwin executable; use ldd see the DLLs that it uses. > Since your shortcut is not starting a windows GUI program, it starts a > console window, possibly executing cmd.exe Depends on the way shortcut is constructed... I don't think it ever touch cmd.exe, there's no need to do so. But the console window is really the run.exe itself. Most, if not all, of Cygwin applications are in fact "console applications" in Windows terms. > Have you tried changing the shortcut to cause it to open the window > minimized? I vaguely remember doing something like that with the > cygwin.bat clone I used to start a (non-X windows) rxvt window. That may at least alleviate the window flashing in the face of a user. -- WBR, Andrey Repin (anrdae...@yandex.ru) 23.10.2014, <5:25> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Wed 2014-10-22 11:23, Corinna Vinschen wrote: > For your convenience I wrote new documentation. Since this is a TEST > prerelease, the new documentation is not part of the official docs yet. > Rather have a look at > > https://cygwin.com/preliminary-ntsec.html "machine is no domain member" -> "machine is not a domain member" -- Tom Schutter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Wed 2014-10-22 11:23, Corinna Vinschen wrote: > The major change in this new release is the new method to read account > (passwd and group) information from the Windows user databases directly, > without the requirement to generate /etc/passwd and /etc/group files to > generate Unix-like uid and gid. What do you think the performance implications of this change will be? -- Tom Schutter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On October 23, 2014 5:00:03 AM CEST, Tom Schutter wrote: >On Wed 2014-10-22 11:23, Corinna Vinschen wrote: >> The major change in this new release is the new method to read >account >> (passwd and group) information from the Windows user databases >directly, >> without the requirement to generate /etc/passwd and /etc/group files >to >> generate Unix-like uid and gid. > >What do you think the performance implications of this change will be? For most home users there will be not much of a difference, probably, but I'm not sure. The older method reading the files was slow, because each exec'ed process had to reread the entire passwd and group files anew. With small files this was probably sufficiently fast. The new method will not have to read any files, though. It reads all infos from the local SAM, and it cashes the user and primary group data right fron the start. If i may hazard a guess, it should be slightly faster for most people. For AD users the answer is probably an "it depends". A slow network might be a problem. But one advantage always is: No more reading /etc/passwd and /etc/group files in each exec'ed process. Corinna - -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJEBAEBCgAuBQJUSJzOJxxDb3Jpbm5hIFZpbnNjaGVuIDxjb3Jpbm5hQHZpbnNj aGVuLmRlPgAKCRD1NgadrkRPoFrJD/sGpUaz/l4ENPsXQmVGph1ZPrkeT60etgQU MOh25sg9/V9td3cDnxX7gLZeGQL+vCeYJFIKuzAtmoO5Ez/7ztfmvK1qHxK4DE3J 0MYL3SDSEm3xFUcxu5Qx58MwXBuupzPz3cC1xI493cmsBHkTHNGf5SLLrKUVIfTY luB6eURygPXm5CDRz2sgstm1AiUfQEqyzl/Pp7b8iESaPEd+rVXjoVmAxcJVEQoT AItBmG3eGy8sLUq1DlkYl8V8nThdCD9LyBxeZlNH7N2T3zyceVnCXF6mIb9127Bs uISei5z+ATDsYFm04dfhgAmJcrQxT2S/XxYwEeO9XxpngpyCcB32EWB0OcRuFOxu xcd6FS4uLYZetIOegXAixsH5JHqDSboW+LPGETpL73tX6vr/gg/q2pOKRhwU4FSo mBF/pqG4B1vXjJqDkM46QKBjoClQSOcWIJiIVzwz/PTHXVFO2dm7MyeuvBDTz2h7 RBaBrjYdz3OF80SgXQFakbXXg5/dOzyJfHRPQcpvSfPG7wuOY3wSXsiH5vyB/k6x A+LhNqHi0C8DkB9Pja9DKuLlte7g+YapSfDsfKJrKucq2QovVsrDszqhnxwMkAsQ sUPH0+7UOonDQ1lyyGSfNkFV7H44gZF0XfiEcxNXdOJu1pIXut6nmVK7QYDouOtB Jt3XsHPUug== =f5z+ -END PGP SIGNATURE- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
