bc version has issue with \r when run from cmd

[dapiot holmp]

the version of bc that comes with cygwin, is bc 1.06.95   it works
fine from within the cygwin environment, but from cmd it doesn't
process \r

C:\cygwin\bin>echo 5+4|.\bc
(standard_in) 1: illegal character: ^M

C:\cygwin\bin>

C:\cygwin\bin>echo 5+4|tr -d '\r'|.\bc
9

C:\cygwin\bin>


Whereas I notice that Gow uses 1.06

And that does work with \r in cmd

C:\Program Files (x86)\Gow\bin>.\bc -v
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 F

C:\Program Files (x86)\Gow\bin>

And  it works fine with \r

C:\Program Files (x86)\Gow\bin>echo 5+4|.\bc
9

C:\Program Files (x86)\Gow\bin>

--
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: failed configure

[Brian Inglis]

On 2016-10-19 09:09, juan carlos Rebate wrote:

2016-10-19 5:33 GMT+02:00 Brian Inglis :

On 2016-10-18 20:10, juan carlos Rebate wrote:

2016-10-19 3:50 GMT+02:00 Brian Inglis :

On 2016-10-18 19:15, juan carlos Rebate wrote:

2016-10-19 2:31 GMT+02:00 René Berber :

On 10/18/2016 7:04 PM, juan carlos Rebate wrote:

in the three applications receive the same error
error cc either not exit or no work,

First check that gcc is in the path, something like this (in mintty):
$ which gcc
/usr/bin/gcc
$ which cc
/usr/bin/cc

but this is not true, when I call to gcc works correctly, todod
tutorials tell me that do the following ./configure --cc=gcc or
./configure --cc="gcc-3 -mno-cygwin" --host-cc=gcc-3

Wrong, useless, tutorials.  What you really do, if needed (and it
really
shouldn't be needed, see above).
./configure CC=gcc
In fact you can learn that by simply running:
./configure --help

On Unix most executables have no extension, so Cygwin does not always
show the .exe following a program name, and /usr/bin/gcc is the normal
Cygwin output for the compiler gcc.exe, and is not a folder name.
If you look for the file under Windows Explorer, you will see the
directory entry for gcc.exe, unless you hide extensions.
Please run Cygwin using the Cygwin Terminal Start Menu Entry;
in that window, cd to the directory where the program configure script
was downloaded; run the following command:
./configure && make
without adding any other options, and post the output in a reply here.

jc@DESKTOP-A72U7VL ~/qemu
$  ./configure && make
ERROR: "cc" either does not exist or does not work

Okay you said earlier:

no on C:\cygwin\usr no gcc folder but if the mingw32 folder, this is
vygwin error because the whole development category is installed

which implies you installed MinGW, not Cygwin, tools, causing the issue.
You should ask about using these tools on the MinGW mailing list, see:
https://sourceforge.net/p/mingw/mailman/mingw-users/
after reading and following:
http://www.mingw.org/wiki/Getting_Started
http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite
http://www.mingw.org/wiki/MinGW_for_First_Time_Users_HOWTO

I do not understand what I said, I said that from the installation
graphical cygwin instaé entire category development to avoid
dependency problems, was cygwin who installed mingw instead of gcc so
that nueevo indicate that failure cygwin


If you *successfully* installed the entire Cygwin Base + Development
categories, you would at least have gcc and cc symlinked to gcc available.
Whether you would be able to run anything without address space
exhaustion would be the likely issue.
Please check Cygwin /var/log/setup.log.full to see if errors were
reported during installation - attach the log in a reply if so.

Else please follow the Cygwin problem reporting guidelines and attach
the output from running cygcheck -svr > cygcheck.txt to a reply post.

--
Take care. Thanks, Brian Inglis, 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: Detecting case sensitivity

[Ken Brown]

On 10/19/2016 7:10 AM, Corinna Vinschen wrote:

On Sep 20 18:03, Ken Brown wrote:

I found an old discussion
(https://www.cygwin.com/ml/cygwin/2007-08/msg00594.html) about the
possibility of adding a _PC_CASE_INSENSITIVE flag to pathconf.  Has anyone
thought further about this?  I would find this useful for emacs[*].

I've taken a quick look at the pathconf code, and it looks like it wouldn't
be difficult to add this.  I could try to provide a patch if the powers that
be would be receptive.


/me marks herself as being receptive


Should the getconf utility be patched to support the new 
_PC_CASE_INSENSITIVE flag?  I'm asking because getconf doesn't currently 
support the Cygwin-only flags _PC_POSIX_PERMISSIONS and 
_PC_POSIX_SECURITY.  This seems to contradict the documentation at 
https://cygwin.com/cygwin-ug-net/getconf.html:


"...getconf serves as a wrapper for the pathconf function, supporting 
the symbolic constants defined in the unistd.h header, without the _PC_ 
prefix."


If the omission of _PC_POSIX_PERMISSIONS and _PC_POSIX_SECURITY was just 
an oversight, I can add support for them along with my patch.


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: chere and environment variable preparation

[Marco Atzeri]

On 19/10/2016 16:47, Nellis, Kenneth wrote:

Normally, I open a Cygwin terminal window by clicking on a Windows icon
which is an alias to a .BAT file which prepares environment variables
for my Cygwin session and then invokes mintty thusly:

start /b C:\cygwin64\bin\mintty -i/Cygwin-Terminal.ico -s80,57 -



Nothing unusual there, but I have come to rely on the chere package,
which seems to invoke mintty directly, so doesn't prepare my
environment variables.


"chere -h"
for the invocation options



Wondering if anyone has solved that problem.

--Ken Nellis



Which problem ?
I set my environment  variables on  ".bashrc"

Regards
Marco


--
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: gdb 7.11.1-2 started within emacs fails

[William M. (Mike) Miller]

On Wed, Oct 19, 2016 at 12:54 PM, Corinna Vinschen
 wrote:
> On Oct 19 12:46, Rockefeller, Harry wrote:
>> >-Original Message-
>> >From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf 
>> >Of William M. (Mike) Miller
>> >Sent: Wednesday, October 19, 2016 10:30 AM
>> >To: cygwin@cygwin.com
>> >Subject: Re: gdb 7.11.1-2 started within emacs fails
>> [snip]
>> >>>I can confirm that this happens also with gdb-7.11.1-1 but not
>> >>>gdb-7.10.1-1.  (I tested on x86_64, since gdb-7.10.1-1 is broken on x86.)
>> >>>It also fails with M-x gdb instead of M-x gud-gdb, but with a different 
>> >>>error message:
>> >>>Failed to resume program execution (ContinueDebugEvent failed, error
>> >>>87) Ken
>> >>
>> >> I tried using 'ddd' instead of emacs and gdb aborts with the same 
>> >> readline ... message above.
>>
>> >Any progress on the above issue? I recently updated my gdb and am running 
>> >into the same problem.
>> >William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com
>>
>> No progress I am aware of.  I switched over to 64-bit Cygwin which uses 
>> gdb-7.10.1-1 to avoid this problem.
>> This "request" may be related to the problem: I would like to see the 
>> autogenerated gdb line:
>> "---Type  to continue, or q  to quit---" to go away.
>> gdb pauses posting this line unnecessarily.
>
> https://sourceware.org/gdb/wiki/FAQ#How_do_I_disable_the_.22Type_.3Creturn.3E_to_continue.2C_or_q_.3Creturn.3E_to_quit.22_pagination_prompt_in_GDB.3F

Thanks for the reference. I don't know why the OP thought that might
have been related to the gdb crash, but it didn't do anything to help
with that when I tried it.

-- 
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.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: gdb 7.11.1-2 started within emacs fails

[Corinna Vinschen]

On Oct 19 12:46, Rockefeller, Harry wrote:
> >-Original Message-
> >From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf Of 
> >William M. (Mike) Miller
> >Sent: Wednesday, October 19, 2016 10:30 AM
> >To: cygwin@cygwin.com
> >Subject: Re: gdb 7.11.1-2 started within emacs fails
> [snip]
> >>>I can confirm that this happens also with gdb-7.11.1-1 but not
> >>>gdb-7.10.1-1.  (I tested on x86_64, since gdb-7.10.1-1 is broken on x86.)
> >>>It also fails with M-x gdb instead of M-x gud-gdb, but with a different 
> >>>error message:
> >>>Failed to resume program execution (ContinueDebugEvent failed, error
> >>>87) Ken
> >>
> >> I tried using 'ddd' instead of emacs and gdb aborts with the same readline 
> >> ... message above.
> 
> >Any progress on the above issue? I recently updated my gdb and am running 
> >into the same problem.
> >William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com
> 
> No progress I am aware of.  I switched over to 64-bit Cygwin which uses 
> gdb-7.10.1-1 to avoid this problem.
> This "request" may be related to the problem: I would like to see the 
> autogenerated gdb line:
> "---Type  to continue, or q  to quit---" to go away.
> gdb pauses posting this line unnecessarily.

https://sourceware.org/gdb/wiki/FAQ#How_do_I_disable_the_.22Type_.3Creturn.3E_to_continue.2C_or_q_.3Creturn.3E_to_quit.22_pagination_prompt_in_GDB.3F


Corinna

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


signature.asc
Description: PGP signature

RE: gdb 7.11.1-2 started within emacs fails

[Rockefeller, Harry]

>-Original Message-
>From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf Of 
>William M. (Mike) Miller
>Sent: Wednesday, October 19, 2016 10:30 AM
>To: cygwin@cygwin.com
>Subject: Re: gdb 7.11.1-2 started within emacs fails
[snip]
>>>I can confirm that this happens also with gdb-7.11.1-1 but not
>>>gdb-7.10.1-1.  (I tested on x86_64, since gdb-7.10.1-1 is broken on x86.)
>>>It also fails with M-x gdb instead of M-x gud-gdb, but with a different 
>>>error message:
>>>Failed to resume program execution (ContinueDebugEvent failed, error
>>>87) Ken
>>
>> I tried using 'ddd' instead of emacs and gdb aborts with the same readline 
>> ... message above.

>Any progress on the above issue? I recently updated my gdb and am running into 
>the same problem.
>William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com

No progress I am aware of.  I switched over to 64-bit Cygwin which uses 
gdb-7.10.1-1 to avoid this problem.
This "request" may be related to the problem: I would like to see the 
autogenerated gdb line:
"---Type  to continue, or q  to quit---" to go away.
gdb pauses posting this line unnecessarily.

Re: gdb 7.11.1-2 started within emacs fails

[William M. (Mike) Miller]

On Thu, Sep 29, 2016 at 11:21 AM, Rockefeller, Harry
 wrote:
>
>>-Original Message-
>>From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf Of 
>>Ken Brown
>>Sent: Tuesday, September 27, 2016 3:16 PM
>>To: cygwin@cygwin.com
>>Subject: Re: gdb 7.11.1-2 started within emacs fails
>
>>On 9/27/2016 2:47 PM, Rockefeller, Harry wrote:
>>> Using program foo:
>>>   program foo
>>>   e = 1.0
>>>   stop
>>>   end
>>>
>>> $ /usr/bin/gfortran-g foo.f -o foo
>>>
>>> Emacs version info: GNU Emacs 25.1.1 (i686-pc-cygwin, GTK+ Version
>>> 3.18.9) of 2016-09-17
>>>
>>> Inside emacs I ran M-x gud-gdb and got ... GNU gdb (GDB) (Cygwin
>>> 7.11.1-2) 7.11.1 ...
>>> (gdb) b 1
>>> Breakpoint 1 at 0x4011d6: file foo.f, line 1.
>>> (gdb) r
>>> Starting program: /cygdrive/c/Users/harryr/foo.exe [New Thread
>>> 6296.0x22ac] [New Thread 6296.0x24d4]
>>> readline: readline_callback_read_char() called with no handler!
>>> Debugger aborted (core dumped)
>>>
>>> Foo written in C++ also fails with the same message.
>>> Running gdb foo in bash gives the expected result:
>>> gdb stops at first executable line prompting for next gdb command.
>>I can confirm that this happens also with gdb-7.11.1-1 but not gdb-7.10.1-1.  
>>(I tested on x86_64, since gdb-7.10.1-1 is broken on x86.)
>>It also fails with M-x gdb instead of M-x gud-gdb, but with a different error 
>>message:
>>Failed to resume program execution (ContinueDebugEvent failed, error 87)
>>Ken
>
> I tried using 'ddd' instead of emacs and gdb aborts with the same readline 
> ... message above.

Any progress on the above issue? I recently updated my gdb and am
running into the same problem.

-- 
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.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: falled compilations

[juan carlos Rebate]

2016-10-19 5:33 GMT+02:00 Brian Inglis :
> On 2016-10-18 20:10, juan carlos Rebate wrote:
>>
>> 2016-10-19 3:50 GMT+02:00 Brian Inglis :
>>>
>>> On 2016-10-18 19:15, juan carlos Rebate wrote:

 2016-10-19 2:31 GMT+02:00 René Berber :
>
> On 10/18/2016 7:04 PM, juan carlos Rebate wrote:
>>
>> in the three applications receive the same error
>> error cc either not exit or no work,
>
> First check that gcc is in the path, something like this (in mintty):
> $ which gcc
> /usr/bin/gcc
> $ which cc
> /usr/bin/cc
>>
>> but this is not true, when I call to gcc works correctly, todod
>> tutorials tell me that do the following ./configure --cc=gcc or
>> ./configure --cc="gcc-3 -mno-cygwin" --host-cc=gcc-3
>
> Wrong, useless, tutorials.  What you really do, if needed (and it
> really
> shouldn't be needed, see above).
> ./configure CC=gcc
> In fact you can learn that by simply running:
> ./configure --help
>>>
>>> On Unix most executables have no extension, so Cygwin does not always
>>> show the .exe following a program name, and /usr/bin/gcc is the normal
>>> Cygwin output for the compiler gcc.exe, and is not a folder name.
>>> If you look for the file under Windows Explorer, you will see the
>>> directory entry forgcc.exe, unless you hide extensions.
>>> Please run Cygwin using the Cygwin Terminal Start Menu Entry;
>>> in that window, cd to the directory where the program configure script
>>> was downloaded; run the following command:
>>> ./configure && make
>>> without adding any other options, and post the output in a reply here.
>>
>> jc@DESKTOP-A72U7VL ~/qemu
>> $  ./configure && make
>>
>> ERROR: "cc" either does not exist or does not work
>
>
> Okay you said earlier:
>
 no on C:\cygwin\usr no gcc folder but if the mingw32 folder, this is
 vygwin error because the whole development category is installed
>
>
> which implies you installed MinGW, not Cygwin, tools, causing the issue.
>
> You should ask about using these tools on the MinGW mailing list, see:
>
> https://sourceforge.net/p/mingw/mailman/mingw-users/
>
> after reading and following:
>
> http://www.mingw.org/wiki/Getting_Started
> http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite
> http://www.mingw.org/wiki/MinGW_for_First_Time_Users_HOWTO
>
> --
> Take care. Thanks, Brian Inglis, 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
>
I do not understand what I said, I said that from the installation
graphical cygwin instaé entire category development to avoid
dependency problems, was cygwin who installed mingw instead of gcc so
that nueevo indicate that failure cygwin

--
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: case sensitivity bug?

[Ken Brown]

On 10/19/2016 7:27 AM, Corinna Vinschen wrote:

On Sep 20 20:33, Ken Brown wrote:

I've set up my Cygwin installation to be case sensitive, following the 
instructions at

https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

But it doesn't seem to be working as I expect.  For example:

$ mkdir a

$ mkdir A

$ ls -al [aA]
a:
total 100
drwxr-xr-x+ 1 kbrown   None 0 2016-09-20 20:18 ./
drwxrwxrwt+ 1 kbrown-admin None 0 2016-09-20 20:19 ../

A:
total 100
drwxr-xr-x+ 1 kbrown   None 0 2016-09-20 20:19 ./
drwxrwxrwt+ 1 kbrown-admin None 0 2016-09-20 20:19 ../

$ mv a A
mv: cannot move 'a' to a subdirectory of itself, 'A/a'

Why does mv think that A and a are the same directory?

Here's another example, where mv should simply do a rename, but it doesn't:

$ rmdir A

$ mv a A

$ ls -al a
total 100
drwxr-xr-x+ 1 kbrown   None 0 2016-09-20 20:18 ./
drwxrwxrwt+ 1 kbrown-admin None 0 2016-09-20 20:30 ../

$ ls -al A
ls: cannot access 'A': No such file or directory

cygcheck output is attached.


Looks like a *very* old misbehaviour.  I applied a patch to Cygwin
to fix this.  I'll create a snapshot later today, please test.


That fixes it.  Thanks.

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

chere and environment variable preparation

[Nellis, Kenneth]

Normally, I open a Cygwin terminal window by clicking on a Windows icon 
which is an alias to a .BAT file which prepares environment variables 
for my Cygwin session and then invokes mintty thusly:

start /b C:\cygwin64\bin\mintty -i/Cygwin-Terminal.ico -s80,57 -

Nothing unusual there, but I have come to rely on the chere package, 
which seems to invoke mintty directly, so doesn't prepare my 
environment variables.

Wondering if anyone has solved that problem.

--Ken Nellis


--
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: rename syscall failed with EACES and os returns NT_STATUS_TRANSACTIONAL_CONFLICT

[Corinna Vinschen]

On Oct  5 17:56, Rinrin wrote:
> Hi:
>   I'm trying to run some unittests with python os.rename function. But
> rename syscall failed with error code 13. From strace output I can see
> windows OS returns NT_STATUS_TRANSACTIONAL_CONFLICT(0xC0190001).
> 
> python2.7 2576 unlink_nt: Opening
> \??\C:\Portable\PrivData\cygwin\tmp\tmp4enMfR for delete failed, status
> = 0xC0190001
> 
>   see http://pastebin.com/iTwDN82S for full log of strace output.
>   I'm on Win 10 x64, Cygwin dll version is 2.6.0, still trying to make a
> demo to represent this issue.

This is weird.  A transaction is only started by Cygwin if the file
has the R/O DOS bit set, and Cygwin does not set this bit (unless
you use FAT or the "noacl" mount flag.

If this error is emitted for files without htis bit set, it's not
Cygwin's fault in the first place.


Corinna

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


signature.asc
Description: PGP signature

Re: Cygwin 2.6.0: unreadable UTF-8 in Windows console

[Corinna Vinschen]

On Oct  1 05:13, Ivan Vanyushkin wrote:
> Something has changed in version 2.6.0, and now UTF-8 text can't be displayed 
> in Windows console (cmd).
> 
> 1. Create a file "test.txt" with non-ASCII text in UTF-8 encoding.
> 2. Run "cmd".
> 3. Run:
> 
> C:\Cygwin\bin\cat test.txt
>  ▒▒  ▒▒ 8000 ▒▒.  
> ▒▒ ▒▒.
> 
> Non-ASCII text is not readable. Older Cygwin 2.5.2 has no such issue.
> 
> C:\Cygwin\bin\uname -a
> CYGWIN_NT-10.0 PCName 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin
> 
> C:\Cygwin\bin\locale
> LANG=
> LC_CTYPE="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_ALL=
> 
> Same issue with any other commands like "grep", or with utilities built and 
> run under Cygwin 2.6.0.
> Same issue in other Windows consoles, like ConEmu or FAR Manager.
> If I change Windows console encoding to UTF-8 (run: "chcp 65001"), file can 
> be correctly displayed natively
> (run: "type test.txt"), but Cygwin "cat" still has the same issue.
> 
> How should I display UTF-8 now?

I applied a patch to fix this regression and uploaded a developer
snapshot with this change to https://cygwin.com/snapshots/

Please test.  Just exchanging the Cygwin DLL is sufficient, no need to
install the entire package.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: Unknown+User Unix_Group+505 on smb shares in a domian

[Corinna Vinschen]

On Sep 29 10:38, Roland Schwingel wrote:
> Hi to all..
> 
> I have the very similar problem.
> 
> >> > I can't do anything, it just becomes an inconvenience.
> >> > d---r-x---+ 1 NT SERVICE+TrustedInstaller NT
> SERVICE+TrustedInstaller 0 Sep 26 08:50 c
> >> > drwxrwx---+ 1 Administrators  Domain Users0 Sep
> 14 11:57 i
> >> > drwxrwx---+ 1 SYSTEM  SYSTEM0 Sep 26
> 12:55 j
> >> > drwxrwx---+ 1 Administrators  Domain Users0 Sep
> 27 07:55 m
> >> > drwxr-xr-x  1 rootieng6_root0 Jul
> 12 04:04 v
> >> > drwxrwxr-x  1 Unknown+UserUnix_Group+5050
> Sep 21 09:41 w
> >> > drwxrwxr-x  1 Unix_User+99Unix_Group+1010
> Sep 21 15:20 y
> >> >
> >>
> 
> > You can tell your IT dep to pull their asses up and join all servers > to
> AD. That would be a much more straightforward solution.
> 
> My servers (linux with samba 4.4) are joined to the domain. An older
> cygwin 1.7 does not show this problem. Presently this problem hinders
> myself for quite some while to move to a newer cygwin version.
> 
> In my case it shows something like:
> -rwx-- 1 Unix_User+roland Unix_Group+develop  25 Sep 11 13:13 test.png
> 
> And some file operations fail in cygwin (2.4.1 - this was my last version I
> have tried) - mostly writting to the files, while writting to the files from
> windows directly works...
> 
> Any help would also be appreciated.

There is a server-side solution for this problem, outlined in the docs:

https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba

HTH,
Corinna

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


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Corinna Vinschen]

On Oct  2 11:59, Thomas Wolff wrote:
> Am 31.08.2016 um 15:58 schrieb Corinna Vinschen:
> > Hi folks,
> > 
> > 
> > I uploaded a new Cygwin release 2.6.0-1.
> > 
> > ...
> Somehow the way to setup the default locale has changed; raising problems as
> described in https://cygwin.com/ml/cygwin/2016-10/msg0.html .
> This affects also bash (without -l). It is "healed" per /etc/profile.
> However, in all previous versions since 1.7 UTF-8 was the official default
> deployed from the cygwin DLL already, so calling cygwin apps from a Windows
> command line would work as expected, which is a valid use case. I don't
> think this change was on purpose.
> 
> > - Support for POSIX-1.2008 locale objects and per-thread locales.
> Maybe it slipped in here?

It did.  I missed a conversion test in the console code.  I applied
a patch to fix this (commit 5a3496c3) and I'll create a snapshot later
today.  Please test.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: case sensitivity bug?

[Corinna Vinschen]

On Sep 20 20:33, Ken Brown wrote:
> I've set up my Cygwin installation to be case sensitive, following the 
> instructions at
> 
> https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
> 
> But it doesn't seem to be working as I expect.  For example:
> 
> $ mkdir a
> 
> $ mkdir A
> 
> $ ls -al [aA]
> a:
> total 100
> drwxr-xr-x+ 1 kbrown   None 0 2016-09-20 20:18 ./
> drwxrwxrwt+ 1 kbrown-admin None 0 2016-09-20 20:19 ../
> 
> A:
> total 100
> drwxr-xr-x+ 1 kbrown   None 0 2016-09-20 20:19 ./
> drwxrwxrwt+ 1 kbrown-admin None 0 2016-09-20 20:19 ../
> 
> $ mv a A
> mv: cannot move 'a' to a subdirectory of itself, 'A/a'
> 
> Why does mv think that A and a are the same directory?
> 
> Here's another example, where mv should simply do a rename, but it doesn't:
> 
> $ rmdir A
> 
> $ mv a A
> 
> $ ls -al a
> total 100
> drwxr-xr-x+ 1 kbrown   None 0 2016-09-20 20:18 ./
> drwxrwxrwt+ 1 kbrown-admin None 0 2016-09-20 20:30 ../
> 
> $ ls -al A
> ls: cannot access 'A': No such file or directory
> 
> cygcheck output is attached.

Looks like a *very* old misbehaviour.  I applied a patch to Cygwin
to fix this.  I'll create a snapshot later today, please test.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

[newlib-cygwin] Don't check directories always case-insensitive in rename(2)

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e3ccb686104103898ac9615a72f0189aa980c273

commit e3ccb686104103898ac9615a72f0189aa980c273
Author: Corinna Vinschen 
Date:   Wed Oct 19 13:26:03 2016 +0200

Don't check directories always case-insensitive in rename(2)

Long-standing problem in one of the corner cases of rename(2):
If we rename a directory a check is performed to see if newpath is
identical to oldpath or a subdir of oldpath. This check is
(accidentally? no hints anywhere in ChangeLogs or code) performed
case-insensitive for as long as we use Unicode paths and NT functions.
This leads to the problems described in
https://cygwin.com/ml/cygwin/2016-09/msg00264.html

Change this to be conditional case-sensitive as all other checks but
let's take this with a grain of salt.  There may be corner-cases in
this corner-case which require to chek parts of the path always
case-insensitive.  Off the top of my head I can't construct such a
case but that's no proof they don't exist :}

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.6.1 | 3 +++
 winsup/cygwin/syscalls.cc   | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/release/2.6.1 b/winsup/cygwin/release/2.6.1
index 2d5aef8..61ce2de 100644
--- a/winsup/cygwin/release/2.6.1
+++ b/winsup/cygwin/release/2.6.1
@@ -11,3 +11,6 @@ Bug Fixes
 
 - Fix regression in console charset handling
   Addresses: https://cygwin.com/ml/cygwin/2016-10/msg0.html
+
+- Fix case-sensitivity problem when renaming directories
+  Addresses: https://cygwin.com/ml/cygwin/2016-09/msg00264.html
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index ba7c743..13bb309 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2224,7 +2224,7 @@ rename (const char *oldpath, const char *newpath)
  /* Check for newpath being identical or a subdir of oldpath. */
  if (RtlPrefixUnicodeString (oldpc.get_nt_native_path (),
  newpc.get_nt_native_path (),
- TRUE))
+ oldpc.objcaseinsensitive ()))
{
  if (newpc.get_nt_native_path ()->Length
  == oldpc.get_nt_native_path ()->Length)

Re: Detecting case sensitivity

[Corinna Vinschen]

On Sep 20 18:03, Ken Brown wrote:
> I found an old discussion
> (https://www.cygwin.com/ml/cygwin/2007-08/msg00594.html) about the
> possibility of adding a _PC_CASE_INSENSITIVE flag to pathconf.  Has anyone
> thought further about this?  I would find this useful for emacs[*].
> 
> I've taken a quick look at the pathconf code, and it looks like it wouldn't
> be difficult to add this.  I could try to provide a patch if the powers that
> be would be receptive.

/me marks herself as being receptive


Corinna

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


signature.asc
Description: PGP signature

[newlib-cygwin] Bump Cygwin version to 2.6.1

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ba2851eecacd79d6ec4083bdf1d38b2a53cabdd7

commit ba2851eecacd79d6ec4083bdf1d38b2a53cabdd7
Author: Corinna Vinschen 
Date:   Wed Oct 19 12:52:06 2016 +0200

Bump Cygwin version to 2.6.1

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/include/cygwin/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index 820d28b..1c1402c 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -11,7 +11,7 @@ details. */
changes to the DLL and is mainly informative in nature. */
 
 #define CYGWIN_VERSION_DLL_MAJOR 2006
-#define CYGWIN_VERSION_DLL_MINOR 0
+#define CYGWIN_VERSION_DLL_MINOR 1
 
 /* Major numbers before CYGWIN_VERSION_DLL_EPOCH are incompatible. */

[newlib-cygwin] Fix regression in console charset handling

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=5a3496c3e3c159e6cfb4879f5adae1092927483f

commit 5a3496c3e3c159e6cfb4879f5adae1092927483f
Author: Corinna Vinschen 
Date:   Wed Oct 19 12:48:40 2016 +0200

Fix regression in console charset handling

Commit d16a5630 dropped usage of cygheap's locale functions
in favor of local on-the-fly usage of UTF-8 instead of ASCII.
This allowed to use the current local rather than a fixed
system-wide locale set at startup time.  d16a5630 just missed
to add the ASCII->UTF-8 conversion in the console as well.

Fixes https://cygwin.com/ml/cygwin/2016-10/msg0.html

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fhandler_console.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc
index 45fe882..2d281e0 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -2005,6 +2005,8 @@ fhandler_console::write_normal (const unsigned char *src,
 
   /* The alternate charset is always 437, just as in the Linux console. */
   f_mbtowc = con.get_console_cp () ? __cp_mbtowc (437) : __MBTOWC;
+  if (f_mbtowc == __ascii_mbtowc)
+f_mbtowc = __utf8_mbtowc;
 
   /* First check if we have cached lead bytes of a former try to write
  a truncated multibyte sequence.  If so, process it. */

[newlib-cygwin] Add release msg for 5a3496c

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e1824aea27536dc0357687c1d9022bee0d1ef501

commit e1824aea27536dc0357687c1d9022bee0d1ef501
Author: Corinna Vinschen 
Date:   Wed Oct 19 12:53:58 2016 +0200

Add release msg for 5a3496c

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.6.1 | 13 +
 1 file changed, 13 insertions(+)

diff --git a/winsup/cygwin/release/2.6.1 b/winsup/cygwin/release/2.6.1
new file mode 100644
index 000..2d5aef8
--- /dev/null
+++ b/winsup/cygwin/release/2.6.1
@@ -0,0 +1,13 @@
+What's new:
+---
+
+
+What changed:
+-
+
+
+Bug Fixes
+-
+
+- Fix regression in console charset handling
+  Addresses: https://cygwin.com/ml/cygwin/2016-10/msg0.html