Re: Bad Address with /cygdrive paths

[Barry Roberts]

Attached is the strace output.

Thanks,
Barry

On Wed, Oct 21, 2015 at 5:09 AM, Corinna Vinschen
 wrote:
> On Oct 12 18:59, Barry Roberts wrote:
>> I've used cygwin for lots of years, and this is kind of weird to me.
>> My operations guys set up some Windows Server 2012 R2 servers with
>> Cygwin x86-64 2.2.1.
>>
>> There's a CIFS mount (from an HNAS) that I use a lot that is giving me
>> problems.  For example:
>>
>> $ ls /cygdrive/m/install
>> ls: cannot access /cygdrive/m/install: Bad address
>
> Would you mind to run strace in this scenario:
>
>   $ strace -o ls.trace ls /cygdrive/m/install
>
> and attach the ls.trace file here?
>
>>
>> But:
>> $ ls m:/install
>>
>> Works just great.
>>
>> Using /cygdrive/m I can list the contents of the root of the drive,
>> but I can't read any files.  And any subdirectory just gives me the
>> "Bad address" error.   Everything (except completion) works just fine
>> with m:/ paths.
>>
>> This isn't a huge deal.  I mostly use cygwin on these servers to
>> manage them with scripts, so I've changed my configuration variables
>> to : paths and everything seems to work.  But I did
>> spend nearly half a day figuring this out, so I'm curious if there's a
>> configuration problem or a known issue that my searches haven't
>> uncovered yet.
>
> Nothing I'd be aware of.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat


ls.trace
Description: Binary data
--
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: Jemalloc under CYGWIN

[Yucong Sun]

> What exactly is the malloc problem you're seeing?

The specific problem I'm having is that jemalloc's malloc_init() calls
needs to use pthread_mutex_init()  or even pthread_mutex with a
initializer.   Both in-turn uses malloc, triggering this issue.

A quick fix would be somehow make pthread always use system
malloc/free, which shouldn't be that bad.

Another issue I saw is that jemalloc will use readlink()  for
"/etc/jemalloc.conf" during malloc_init(), which on cygwin, this
function uses "new" to do some path manipulating work, which also have
the same issue.  However, we can probably just disable that .

So, the quickest fix would be to make cygwin's thread implementations
always use system malloc.

some small workarounds in jemalloc would be needed afterwards, but it
should be a nice starting point.

--
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: Error accessing mapped drive >2TB?

[Corinna Vinschen]

On Oct 21 16:03, Andrey Repin wrote:
> Greetings, Corinna Vinschen!

Your mailer is STILL breaking the history, btw.  Could you reconfigure
so the "blah wrote:" header is preserved for each mail in the thread you
still quote?  Thanks.

> > On Oct 21 15:33, Andrey Repin wrote:
> 
> >> Windows does not allow for reparse points to networked locations.
> >> Symlinks all right, directory junctions no.
> 
> > Fine, but then the question is, why is the FILE_ATTRIBUTE_REPARSE_POINT
> > flag set in the first place?
> 
> May be the reparse point was manually tampered with.

How so?  You can't set or clear the FILE_ATTRIBUTE_REPARSE_POINT flag
on an existing file.  The flag seems to be set by the server providing
the drive for some reason.


Corinna


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


pgpNJEExj7NUI.pgp
Description: PGP signature

Re: Jemalloc under CYGWIN

[Corinna Vinschen]

On Oct 21 21:49, Yucong Sun wrote:
> > What exactly is the malloc problem you're seeing?
> 
> The specific problem I'm having is that jemalloc's malloc_init() calls
> needs to use pthread_mutex_init()  or even pthread_mutex with a
> initializer.   Both in-turn uses malloc, triggering this issue.
> 
> A quick fix would be somehow make pthread always use system
> malloc/free, which shouldn't be that bad.

What about using a native critical section instead?  It shouldn't be too
tricky to conditionalize this in jemalloc.

> Another issue I saw is that jemalloc will use readlink()  for
> "/etc/jemalloc.conf" during malloc_init(), which on cygwin, this
> function uses "new" to do some path manipulating work, which also have
> the same issue.  However, we can probably just disable that .

Or alternatively the file can be reasd like the other files in /etc
Cygwin needs early access to.  See the NT_readline class and an
example usage in, e.g, mount_info::from_fstab.

> So, the quickest fix would be to make cygwin's thread implementations
> always use system malloc.
> 
> some small workarounds in jemalloc would be needed afterwards, but it
> should be a nice starting point.


Corinna

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


pgpznASkPlepw.pgp
Description: PGP signature

Re: Jemalloc under CYGWIN

[Yucong Sun]

On Wed, Oct 21, 2015 at 10:15 PM, Corinna Vinschen
 wrote:
> On Oct 21 21:49, Yucong Sun wrote:
>> > What exactly is the malloc problem you're seeing?
>>
>> The specific problem I'm having is that jemalloc's malloc_init() calls
>> needs to use pthread_mutex_init()  or even pthread_mutex with a
>> initializer.   Both in-turn uses malloc, triggering this issue.
>>
>> A quick fix would be somehow make pthread always use system
>> malloc/free, which shouldn't be that bad.
>
> What about using a native critical section instead?  It shouldn't be too
> tricky to conditionalize this in jemalloc.

Possibly, jemalloc already have support of this.  However I wasn't so
sure that this was possible before,

see 
https://github.com/jemalloc/jemalloc/blob/dev/include/jemalloc/internal/mutex.h#L80

--
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 1.4 bug(?) - "Bash Prompt Here" not shown under Libraries folders

[cpengr]

The folders I'm talking about *are* located on the filesystem, so you
certainly can cd to them.

This is evidenced by the path shown when you click on the location
bar. And also, as described, it works when you click on the folders
themselves (even if you browse to them via Libraries), but doesn't
work when you click the empty space from inside the same folders.

This should work.

cpengr

On 10/21/15, Achim Gratz  wrote:
> cpengr writes:
>> Under certain circumstances, when I right-click in the empty space in
>> Windows Explorer, in any folder or subfolder beneath any "Libraries"
>> folder (e.g. my "Documents"), the "Bash Prompt Here" option is not
>> shown in the context menu.
>
> "Libraries", despite the looks in Explorer, isn't a folder and not a
> place you can set the current directory to.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Samples for the Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
>
> --
> 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: Jemalloc under CYGWIN

[Corinna Vinschen]

On Oct 21 22:43, Yucong Sun wrote:
> On Wed, Oct 21, 2015 at 10:15 PM, Corinna Vinschen
>  wrote:
> > On Oct 21 21:49, Yucong Sun wrote:
> >> > What exactly is the malloc problem you're seeing?
> >>
> >> The specific problem I'm having is that jemalloc's malloc_init() calls
> >> needs to use pthread_mutex_init()  or even pthread_mutex with a
> >> initializer.   Both in-turn uses malloc, triggering this issue.
> >>
> >> A quick fix would be somehow make pthread always use system
> >> malloc/free, which shouldn't be that bad.
> >
> > What about using a native critical section instead?  It shouldn't be too
> > tricky to conditionalize this in jemalloc.
> 
> Possibly, jemalloc already have support of this.  However I wasn't so
> sure that this was possible before,
> 
> see 
> https://github.com/jemalloc/jemalloc/blob/dev/include/jemalloc/internal/mutex.h#L80

Yes, that looks good.  Please use critical sections for the time being.
We're going to drop XP support end of this year, but up to that point we
can't use SRW locks.


Thanks,
Corinna

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


pgpNsE9ojfvdf.pgp
Description: PGP signature

Re: Bad Address with /cygdrive paths

[Corinna Vinschen]

On Oct 21 08:24, Barry Roberts wrote:
> Attached is the strace output.

Thanks.

The culprit are apparently some weird User and Group SIDs.

34   22501 [main] ls 3428 build_fh_pc: fh 0x180329B20, dev 00C3
   26   22527 [main] ls 3428 stat_worker: (\??\M:\install, 0x600039B40, 
0x180329B20), file_attributes 16
  539   23066 [main] ls 3428 cygpsid::debug_print: get_sids_info: owner SID = 
S-1-81-0-0
   39   23105 [main] ls 3428 cygpsid::debug_print: get_sids_info: group SID = 
S-1-0
  227   23332 [main] ls 3428 pwdgrp::fetch_account_from_windows: 
LookupAccountSid(S-1-81-0-0), Win32 error 1332
   36   23368 [main] ls 3428 pwdgrp::fetch_account_from_windows: line: 

  198   23566 [main] ls 3428 pwdgrp::fetch_account_from_windows: 
LookupAccountSid(S-1-0), Win32 error 1332
   34   23600 [main] ls 3428 pwdgrp::fetch_account_from_windows: line: 

--- Process 3428, exception c005 at 7FFA1856A774

Granted, it's not nice of Cygwin to SEGV here, but I do wonder where
the SIDs S-1-81-0-0 and S-1-0 are coming from.  They are both invalid
as far as I can see.

Hmm.  The problem is to reproduce this to find out where this happens.
The exception address is inside a Windows DLL :-P


Corinna

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


pgpZuSjaaIs3z.pgp
Description: PGP signature

Re: upset, genini: different version ordering

[Yaakov Selkowitz]

On Wed, 2015-10-21 at 18:45 +0200, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> >> and I don't see why any of you would like the idea.
> >
> > Because it is a well-established solution for the same issue on other
> > platforms.
> 
> I have never seen this used (I don't claim it isn't used somewhere, mind
> you) and I still can't think of a good reason for why anybody should.

https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs

> And "other platforms", including those that use plain rpm, seem to be
> using fine-grained versioned dependencies in the concrete scenario
> you've outlined.

That's not related to this issue.

--
Yaakov

Re: upset, genini: different version ordering

[Achim Gratz]

Yaakov Selkowitz writes:
>> and I don't see why any of you would like the idea.
>
> Because it is a well-established solution for the same issue on other
> platforms.

I have never seen this used (I don't claim it isn't used somewhere, mind
you) and I still can't think of a good reason for why anybody should.

And "other platforms", including those that use plain rpm, seem to be
using fine-grained versioned dependencies in the concrete scenario
you've outlined.  I did look at zypper about a year ago, but
unfortunately the dependencies on other libraries were quite extensive,
so I didn't go forward.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Error accessing mapped drive >2TB?

[Corinna Vinschen]

On Oct 21 09:52, Warren Young wrote:
> On Oct 21, 2015, at 4:03 AM, Corinna Vinschen wrote:
> > 
> > The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
> > to fetch the reparse data it's no reparse point anymore?  How dumb is
> > that?
> > 
> > I can't reproduce this bug with my Samba drives, but it's not actually a
> > bug in Cygwin from my perspective.
> > 
> > Yeah, that observation doesn't really help, so I applied a potential
> > workaround to Cygwin.
> 
> How could we prove that the problem is the Apple SMB server?
> 
> I mean, I know how to snag a stream of SMB packets with Wireshark, but
> I don’t know what I’d be looking for in the dump.

Me neither, the Samba guys might be able to help there, perhaps.
Or, does wireshark know how SMB packages look like OTW?

Alternatively, a native Windows test application like this should
show the same symptom:

  HANDLE handle = CreateFile ("P:\\", ...);
  DWORD attributes = GetFileAttributes (handle);
  if (attributes != (DWORD) -1
  && (attributes & FILE_ATTRIBUTE_REPARSE_POINT))
{
  char buf[32000];
  DWORD len;

  if (!DeviceIoControl(handle, FSCTL_GET_REPARSE_POINT, NULL, 0,
   buf, 32000, , NULL))
printf ("error %u\n", GetLastError ());
}

If so, the error code would be 4390.

> Keep in mind that Windows Explorer seems to cope with this situation,
> so Explorer may be doing something like in your patch.

Yeah, maybe.  Or it doesn't even test for a reparse point in this
scenario.

> > If you're set up to build your own Cygwin, please give it a try.
> 
> Yes, that fixes the symptom here.
> 
> Thanks for chasing this down.

Thanks for testing!


Corinna

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


pgp_7kvVX9CdG.pgp
Description: PGP signature

Re: chere 1.4 bug(?) - "Bash Prompt Here" not shown under Libraries folders

[Achim Gratz]

cpengr writes:
> Under certain circumstances, when I right-click in the empty space in
> Windows Explorer, in any folder or subfolder beneath any "Libraries"
> folder (e.g. my "Documents"), the "Bash Prompt Here" option is not
> shown in the context menu.

"Libraries", despite the looks in Explorer, isn't a folder and not a
place you can set the current directory to.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
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: Error accessing mapped drive >2TB?

[Warren Young]

On Oct 21, 2015, at 4:03 AM, Corinna Vinschen wrote:
> 
> The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
> to fetch the reparse data it's no reparse point anymore?  How dumb is
> that?
> 
> I can't reproduce this bug with my Samba drives, but it's not actually a
> bug in Cygwin from my perspective.
> 
> Yeah, that observation doesn't really help, so I applied a potential
> workaround to Cygwin.

How could we prove that the problem is the Apple SMB server?

I mean, I know how to snag a stream of SMB packets with Wireshark, but I don’t 
know what I’d be looking for in the dump.

Keep in mind that Windows Explorer seems to cope with this situation, so 
Explorer may be doing something like in your patch.

> If you're set up to build your own Cygwin, please give it a try.

Yes, that fixes the symptom here.

Thanks for chasing this down.
--
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

CYGWIN_NT-6.1-WOW 2.2.1(0.289/5/3) inconsistency between pwd and readdir

[Francis ANDRE]

Hi

the drive letter returned by pwd is a upper case letter while the drive 
letter returned by readdir is a lower case letter.


[FrancisANDRE@idefix pocozos ]$pwd
/cygdrive/Z/git/pocozos
[FrancisANDRE@idefix pocozos ]$ll /cygdrive
total 92
drwxrwxrwx+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 
20 oct.  18:52 c

drwxrwxrwt+ 1 Administrateurs Système 0 20 oct.  18:52 d
drwxrwxrwx+ 1 Administrateurs Unknown+Group   0 20 oct.  18:52 g
drwx---rwx+ 1 Administrateurs Administrateurs 0 21 oct.  11:45 z

Thus, when traversing the /cygdrive tree using a pattern matching code, 
the /cygdrive/Z directory does not exist while the /cygdrive/z exists.


Either pwd should return a lower case letter, either readdir should 
return an uppercase drive letter to get consistent results.


FA

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

Missing volumes in output from df -h

[Frank Redeker]

Hello list,

I just noticed 2 missing volumes when executing df -h from inside 
[CYGWIN_NT-6.1 Mimir
2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin]


$ mount
D:/Program_Files_64/cygwin64/bin on /usr/bin type ntfs (binary,auto)
D:/Program_Files_64/cygwin64/lib on /usr/lib type ntfs (binary,auto)
D:/Program_Files_64/cygwin64 on / type ntfs (binary,auto)
B: on /cygdrive/b type ntfs (binary,posix=0,user,noumount,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto)
M: on /cygdrive/m type ntfs (binary,posix=0,user,noumount,auto)
N: on /cygdrive/n type ntfs (binary,posix=0,user,noumount,auto)
O: on /cygdrive/o type smbfs (binary,posix=0,user,noumount,auto)
P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)
T: on /cygdrive/t type ntfs (binary,posix=0,user,noumount,auto)
W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto)


The volumes B: and T: are no real drives but created with subst.

$ subst
B:\: => F:\Projects
T:\: => F:\T


$ df -h
FilesystemSize  Used Avail Use% Mounted on
D:/Program_Files_64/cygwin64  112G   42G   70G  38% /
B:469G   84G  386G  18% /cygdrive/b
C:115G   87G   29G  76% /cygdrive/c
E:463G  215G  249G  47% /cygdrive/e
M:233G   72G  161G  31% /cygdrive/m
N:230G  143G   87G  63% /cygdrive/n
O:856G  751G  105G  88% /cygdrive/o
P:285G  181G  105G  64% /cygdrive/p
W:209G  179G   30G  86% /cygdrive/w

$ df -h /cygdrive/f
Filesystem  Size  Used Avail Use% Mounted on
F:  469G   84G  386G  18% /cygdrive/f


When executing df from inside my old [CYGWIN_NT-6.1-WOW64 Mimir
1.7.33-2(0.280/5/3) 2014-11-13 15:45 i686 Cygwin] the result is somewhat
different. Here drive B: and F: are missing but T: is present.


$ df -h
Filesystem  Size  Used Avail Use% Mounted on
C:  115G   87G   29G  76% /cygdrive/c
T:  469G   84G  386G  18% /cygdrive/t
D:  112G   42G   70G  38% /cygdrive/d
E:  463G  215G  249G  47% /cygdrive/e
M:  233G   72G  161G  31% /cygdrive/m
N:  230G  143G   87G  63% /cygdrive/n
O:  856G  751G  105G  88% /cygdrive/o
P:  285G  181G  105G  64% /cygdrive/p
W:  209G  179G   30G  86% /cygdrive/w


Frank



I tried to report this from my registered mailing list account f.redeker (at) 
razorcat.de. But that mail was rejected because of spam classification. Maybe 
this happend because of the attached cygcheck and strace output.

If the cygcheck and strace is needed to find out what going on I will try send 
it again.



--
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: Proposal to use ThreadQuerySetWin32StartAddress inside munge_threadfunc (Cygwin randomly crashes on Wine)

[Qian Hong]

Hi Corinna,

On Wed, Oct 21, 2015 at 4:17 PM, Corinna Vinschen
 wrote:
> I simplified your patch, taking out the printf's and added a test in the
> loop in case NtQueryInformationThread failed.  See below.  It's not
> overly large, but it introduces new functionality.  It would be nice if
> you could sign a copyright assignment and send it as PDF.  Please see
> https://cygwin.com/assign.txt.

Thank you for the improvement!
I sent an email with my signed pdf to ges-info AT redhat DOT com and
CCed corinna-cygwin AT cygwin DOT com, but it was rejected by
corrina-cygwin AT cygwin DOT com, did I miss anything?




-- 
Regards,
Qian Hong

-
http://www.winehq.org

--
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: [PATCH] Allow overriding the home directory via the HOME variable

[Corinna Vinschen]

On Sep 16 15:06, Johannes Schindelin wrote:
>   * uinfo.cc (cygheap_pwdgrp::get_home): Offer an option in
>   nsswitch.conf that let's the environment variable HOME (or
>   HOMEDRIVE & HOMEPATH, or USERPROFILE) define the home
>   directory.
> 
>   * ntsec.xml: Document the `env` schema.
> 
> Detailed comments:
> 
> In the context of Git for Windows, it is a well-established technique
> to let the `$HOME` variable define where the current user's home
> directory is, falling back to `$HOMEDRIVE$HOMEPATH` and `$USERPROFILE`.
> 
> The idea is that we want to share user-specific settings between
> programs, whether they be Cygwin, MSys2 or not.  Unfortunately, we
> cannot blindly activate the "db_home: windows" setting because in some
> setups, the user's home directory is set to a hidden directory via an
> UNC path (\\share\some\hidden\folder$) -- something many programs
> cannot handle correctly.

-v, please.  Which applications can't handle that?  Why do we have to
care?

> The established technique is to allow setting the user's home directory
> via the environment variables mentioned above.  This has the additional
> advantage that it is much faster than querying the Windows user database.

But it's wrong.  We discussed this a couple of times on the Cygwin ML.
The underlying functionality generically implements the passwd entries.
Your "env" setting will return the same $HOME setting in the pw_dir
field for every user account.  All user accounts will have the same home
dir as your current user.  And the value is unreliable, too.  If another
user logs in, all accounts will have another $HOME, the one from the now
logged in user.  This is so wrong and potentially dangerous that I don't
think this belongs into Cygwin, sorry.


Corinna

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


pgpCZmXQbsoTi.pgp
Description: PGP signature

Bash unable to print epoch timestamp

[Don Harrop]

Bash outputs no value when using it's built in method of printing an 
"epoch" timestamp.


BashCommandLine#: printf '%(%s)T' -1

I've verified the same behavior with others on IRC.

Below are my relevant pieces of cygcheck.exe -s

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Cygwin DLL version info:
DLL version: 2.2.1
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 289
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5

Package  VersionStatus
bash 4.3.42-3   OK
base-cygwin  3.8-1  OK
base-files   4.2-3  OK
cygwin   2.2.1-1OK
util-linux   2.25.2-2   OK


Cheers!
 - Don

--
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: [PATCH] Introduce the 'usertemp' filesystem type

[Corinna Vinschen]

Hi Johannes,

On Oct 20 13:47, Johannes Schindelin wrote:
> On Tue, 20 Oct 2015, Corinna Vinschen wrote:
> > On Sep 16 09:35, Johannes Schindelin wrote:
> > >   * mount.cc (mount_info::from_fstab_line): support mounting the
> > >   current user's temp folder as /tmp/. This is particularly
> > >   useful a feature when Cygwin's own files are write-protected.
> > > 
> > >   * pathnames.xml: document the new usertemp file system type
> 
> BTW I thought this would be the preferred form of the ChangeLog entry: as
> part of the commit message. At least that is how I interpreted this part:
> 
>   ChangeLogs should not be sent as "diffs". Just send the complete
>   ChangeLog entry, which is ideally part of the output of
>   `git format-patch' anyway.
> 
> of https://cygwin.com/contrib.html

Duh, I missed that from your OP.  Somehow I started reading with
"Detailed explanation:".  Sorry about that.

> > > By specifying
> > > 
> > >   none /tmp usertemp binary,posix=0 0 0
> > > 
> > > in /etc/fstab, the /tmp/ directory gets auto-mounted to the directory
> > > specified by the %TEMP% variable.
> > 
> > In theory you could also utilize /etc/fstab.d/$USER, without the need to
> > implement a usertemp mount type.
> 
> This is unfortunately not possible. The use case that triggered this patch
> is Git for Windows (which does not use Cygwin directly, but the MSys2
> runtime which is derived from Cygwin).

Editorial note: 

It's a bit hard to understand why we need Git for Windows while there's
a full fledged git available as part of the Cygwin distro.  It's also
very frustrating that a Git for Windows standalone tool gets a lot of
press coverage while nobody seems to care that Git for Windows under
Cygwin exists for ages.  Sigh.

> Indeed. In Git for Windows' case, this is actually a feature. That way,
> different users' files are encapsulated from each other.
> [...]
> As I said, in a multi-user setting, or even worse: in a portable
> application, this is simply not possible other than via the strategy
> implemented by this patch.

Here's a question.  If it's really only about git, why do you need
to redirect /tmp, rather than having git use $TMP directly?  That would
be much less intrusive than having to change the underlying POSIX
layer, isn't it?

> > - The ChangeLog entry is missing.
> 
> See above. Do you want me to include the diff to winsup/cygwin/ChangeLog?

No, my bad, sorry.

> [...]
> > > +  char mb_tmp[len = sys_wcstombs (NULL, 0, tmp)];
> > 
> > - len = sys_wcstombs() + 1
> 
> Whoops. I always get that wrong.
> 
> But... actually... Did you know that `sys_wcstombs()` returns something
> different than advertised? The documentation says:
> 
>   - dst == NULL; len is ignored, the return value is the number
> of bytes required for the string without the trailing NUL, just
> like the return value of the wcstombs function.
> 
> But when I call
> 
>   small_printf("len of 1: %d\n", sys_wcstombs(NULL, 0, L"1"));
> 
> it prints "len of 1: 2", i.e. the number of bytes requires for the string
> *with* the trailing NUL, disagreeing with the comment in strfuncs.cc.

Drat.  You're right.  As usual I wonder why nobody ever noticed this.
As soon as the nwc parameter is larger than the number of non-0 wchars
in the source string, sys_cp_wcstombs returns the length including the
trailing NUL.

And looking through the Cygwin sources the usage is rather erratic,
sometimes with, sometimes without + 1 :(

> How do you want to proceed from here? Should I fix sys_wcstombs() when the
> fourth parameter is -1? Or is this not a fix, but I would rather break
> things?

No, this needs fixing, but it also would break things.  I have to take
a stab at fixing this throughout Cygwin first.

> > - What about adding a mount flags to allow fillout_mntent to print out
> >   the mount type?  This isn't essential, I'm just wondering if there
> >   might be a good reason to see the type in mount(1) output.
> 
> You mean something like this?
> 
> -- snip --

Yes, that's what I had in mind.


Thanks,
Corinna

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


pgpLfXtKIv52W.pgp
Description: PGP signature

Re: [PATCH] Add ability to use NTFS native directory symlinks without admin rights on XP and later

[Corinna Vinschen]

Hi Evgeny,

Preliminaries: we need a copyright assignment from you before being able
to include your patches.  Please see https://cygwin.com/assign.txt.

On Sep 23 18:23, Evgeny Grin wrote:
> This patch will add ability to create directory junction which are
> supported from Windows 2000 and not require any special rights (unlike
> file/directory symbolic links).
> New three modes for symbolic links creation added: "safenative",
> "safenativestrict" and "safenativeonly". First two allow fallback to
> "native" and "nativesctrict",

I'm not opposed to add functionality to create directory junctions
as symlinks, but I am opposed to adding lots of even more confusing
settings to the CYGWIN=winsymlinks option.

I'm ok to fallback from native symlink to dir junction in both
winsymlinks:native and nativestrict modes.  We could even always use dir
junctions for dirs in the first place and only try to create a symlink
if that fails.  The difference is negligible from a user perspective
anyway.


Thanks,
Corinna

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


pgpChsIk5cb2b.pgp
Description: PGP signature

Re: Error accessing mapped drive >2TB?

[Warren Young]

On Oct 21, 2015, at 10:22 AM, Corinna Vinschen wrote:
> 
> On Oct 21 09:52, Warren Young wrote:
>> 
>> I mean, I know how to snag a stream of SMB packets with Wireshark, but
>> I don’t know what I’d be looking for in the dump.
> 
> Me neither, the Samba guys might be able to help there, perhaps.

Apple hasn’t shipped Samba as part of OS X since 10.6, quite a few years ago 
now.  In 10.7, they switched to an internally-developed SMB server.

> Or, does wireshark know how SMB packages look like OTW?

The build of Wireshark on the machine I’m using right now has about 1,700 
protocol dissectors, which covers pretty much every protocol you’ve ever heard 
of, and hundreds you haven’t.

The trick is, dissecting the packets is only useful if the protocol is human 
readable (SMB isn’t) or you know the protocol (I don’t) or you’re lucky and 
happen to see something you can make sense of.  I was hoping not to have to 
rely on blind luck.

>  HANDLE handle = CreateFile ("P:\\", ...);

I guess I’m not seeing what values to pass to CreateFile() because I get an 
error with the values I’m trying here.  I’ve put my fleshed-out test program 
here:

  http://pastebin.com/BfN2fNBQ

Its complaint is:

  Bad handle: The filename, directory name, or volume label syntax is incorrect.
 (0x7b)

I double-checked, and P: is still mapped.

--
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: CYGWIN_NT-6.1-WOW 2.2.1(0.289/5/3) inconsistency between pwd and readdir

[Andrey Repin]

Greetings, Francis ANDRE!

> the drive letter returned by pwd is a upper case letter while the drive
> letter returned by readdir is a lower case letter.

> [FrancisANDRE@idefix pocozos ]$pwd
> /cygdrive/Z/git/pocozos
> [FrancisANDRE@idefix pocozos ]$ll /cygdrive
> total 92
> drwxrwxrwx+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 
> 20 oct.  18:52 c
> drwxrwxrwt+ 1 Administrateurs Système 0 20 oct.  18:52 d
> drwxrwxrwx+ 1 Administrateurs Unknown+Group   0 20 oct.  18:52 g
> drwx---rwx+ 1 Administrateurs Administrateurs 0 21 oct.  11:45 z

> Thus, when traversing the /cygdrive tree using a pattern matching code, 
> the /cygdrive/Z directory does not exist while the /cygdrive/z exists.

> Either pwd should return a lower case letter, either readdir should 
> return an uppercase drive letter to get consistent results.

$ cd /cygdrive/c/dev/; pwd
/cygdrive/c/dev
$ cd /cygdrive/C/dev/; pwd
/cygdrive/C/dev
$

Notice the pattern.


-- 
With best regards,
Andrey Repin
Wednesday, October 21, 2015 20:57:10

Sorry for my terrible english...

RE: pthread_kill: signals remain pending after target thread exits

[John Carey]

> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Wednesday, October 21, 2015 4:48 AM
> Subject: Re: pthread_kill: signals remain pending after target thread exits
...
> > On Sep 11 18:11, John Carey wrote:
> > There seems to be a problem with pthread_kill: a pending signal
> > targeting a particular thread prevents other threads from receiving
> > signals sharing the same signal number--even after the original target
> > thread exits and is joined.
...
> The important thing here is to get rid of the pending signal.

Yes, I agree that is the most important thing.

> > In my view it would be desirable if:
> >
> >   - Pending signals targeting a particular thread would not outlast
> >   that thread.
> 
> Since you looked into the code anyway, do you have an idea how to
> implement that?  For a start, do you have a simple testcase, only
> the bare code needed to reproduce the issue?

I've attached a test case that I *think* gets into the right spot, at least for 
64-bit Cygwin 2.0.4.  That is, it hangs trying to receive the signal, instead 
of terminating.  (This test passes (terminates) in 32-bit Cygwin 1.7.9 and 
64-bit Ubuntu 14.04.3 LTS.)

As to a fix: sorry, but though I looked at the code, I am not sufficiently 
confident to suggest a specific change.  I think that the internal signal 
handling thread has exclusive access to the pending signal collection, which is 
one difficulty.  And I'm not sure how the race is resolved between something 
trying to use the cygtls and the cygtls being destroyed.  At a guess, there are 
at least two general approaches to a fix:

1. Somehow prevent new signals from being sent to the terminating thread, then 
notify the internal signal handling thread of the need to purge pending signals 
targeting the doomed thread, then delay cygtls destruction until confirmation 
that that purge is complete.

2. In the pending signal representation, replace the direct cygtls address with 
a pointer to some small reference-counted object associated with the cygtls.  
That small object could live on for a while, even after the original cygtls has 
been destroyed and its memory reused for a new cygtls, so that the signal 
processing thread can take its time purging references.  But there has to be 
some way to atomically do two things: 1) check whether this small object still 
points to a valid cygtls, and 2) if it does, delay destruction of that cygtls 
until some task has been performed (such as processing a signal).  Perhaps this 
small object could contain an invalidation flag and some synchronization 
objects (mutex, condition variable, etc.) in addition to the raw cygtls pointer.

> >   - Multiple pending signals targeting different threads could
> >   coexist, even if they shared the same signal number.  This happens
> >   on Linux (Ubuntu 14.04.3), where I can generate two signals for two
> >   different threads, then sleep for a bit in each target thread, and
> >   finally have each thread receive its signal with sigwait()--neither
> >   signal is lost during the sleeping period.
> 
> That requires to extend the handling for pending signals.  That's
> a rather bigger task...

Yeah.  It's nice if threads don't interfere with each other, but this part 
would indeed be harder to change.

-- John Carey
/* Copyright (c) 2015, Electric Cloud, Inc.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 *   - Redistributions of source code must retain the above copyright
 * notice, this list of conditions and the following disclaimer.
 *
 *   - Redistributions in binary form must reproduce the above copyright
 * notice, this list of conditions and the following disclaimer in the
 * documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/* This test program demonstates a Cygwin bug in which a signal sent
 * to a particular thread remains pending after the thread terminates.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t cond = 

Re: Missing volumes in output from df -h

[Andrey Repin]

Greetings, Frank Redeker!

> I just noticed 2 missing volumes when executing df -h from inside 
> [CYGWIN_NT-6.1 Mimir
> 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin]

From your df, there's no "missing" volumes, all real volumes are accounted
for.
subst does not create a new volume, it just maps the drive letter to an
existing path.
(As an OT, it was a long standing Microsoft recommendation to NOT use mapped
drives, if possible. And I can see, why. It literally saved my life on one
occasion, because attacker script enumerated only drive letters.)

> $ mount
> D:/Program_Files_64/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> D:/Program_Files_64/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> D:/Program_Files_64/cygwin64 on / type ntfs (binary,auto)
> B: on /cygdrive/b type ntfs (binary,posix=0,user,noumount,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
> F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto)
> M: on /cygdrive/m type ntfs (binary,posix=0,user,noumount,auto)
> N: on /cygdrive/n type ntfs (binary,posix=0,user,noumount,auto)
> O: on /cygdrive/o type smbfs (binary,posix=0,user,noumount,auto)
> P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)
> T: on /cygdrive/t type ntfs (binary,posix=0,user,noumount,auto)
> W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto)


> The volumes B: and T: are no real drives but created with subst.

> $ subst
> B:\: => F:\Projects
> T:\: => F:\T


> $ df -h
> FilesystemSize  Used Avail Use% Mounted on
> D:/Program_Files_64/cygwin64  112G   42G   70G  38% /
> B:469G   84G  386G  18% /cygdrive/b
> C:115G   87G   29G  76% /cygdrive/c
> E:463G  215G  249G  47% /cygdrive/e
> M:233G   72G  161G  31% /cygdrive/m
> N:230G  143G   87G  63% /cygdrive/n
> O:856G  751G  105G  88% /cygdrive/o
> P:285G  181G  105G  64% /cygdrive/p
> W:209G  179G   30G  86% /cygdrive/w

> $ df -h /cygdrive/f
> Filesystem  Size  Used Avail Use% Mounted on
> F:  469G   84G  386G  18% /cygdrive/f


> When executing df from inside my old [CYGWIN_NT-6.1-WOW64 Mimir
> 1.7.33-2(0.280/5/3) 2014-11-13 15:45 i686 Cygwin] the result is somewhat
> different. Here drive B: and F: are missing but T: is present.

That's still very much understandable. It only count each volume once.

> $ df -h
> Filesystem  Size  Used Avail Use% Mounted on
> C:  115G   87G   29G  76% /cygdrive/c
> T:  469G   84G  386G  18% /cygdrive/t
> D:  112G   42G   70G  38% /cygdrive/d
> E:  463G  215G  249G  47% /cygdrive/e
> M:  233G   72G  161G  31% /cygdrive/m
> N:  230G  143G   87G  63% /cygdrive/n
> O:  856G  751G  105G  88% /cygdrive/o
> P:  285G  181G  105G  64% /cygdrive/p
> W:  209G  179G   30G  86% /cygdrive/w


> I tried to report this from my registered mailing list account f.redeker
> (at) razorcat.de. But that mail was rejected because of spam classification.
> Maybe this happend because of the attached cygcheck and strace output.

> If the cygcheck and strace is needed to find out what going on I will try 
> send it again.


-- 
With best regards,
Andrey Repin
Wednesday, October 21, 2015 20:52:00

Sorry for my terrible english...

Re: Bash unable to print epoch timestamp

[Brian Inglis]

Don Harrop  effx.us> writes:
> Bash outputs no value when using it's built in method of printing an 
> "epoch" timestamp.
> BashCommandLine#: printf '%(%s)T' -1

bash printf depends on underlying strftime in newlib, which does not support
%s, as it is conditional on _WANT_C99_TIME_FORMATS being defined, and that
is presumably not defined in the config, as %s is not shown in man strftime. 
Workaround for now is use 
date +%s 
for current time, and 
   date -d $(printf '%(%T)T' -2) +%s
for shell invocation time.




--
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: Error accessing mapped drive >2TB?

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Oct 21 15:33, Andrey Repin wrote:

>> Windows does not allow for reparse points to networked locations.
>> Symlinks all right, directory junctions no.

> Fine, but then the question is, why is the FILE_ATTRIBUTE_REPARSE_POINT
> flag set in the first place?

May be the reparse point was manually tampered with.

I just ran strace on two ls calls.
On symlink to a network share

 1962   29951 [main] ls 28776 lstat64: entering
   18   29969 [main] ls 28776 normalize_posix_path: src /c/arc
   15   29984 [main] ls 28776 normalize_posix_path: /c/arc = 
normalize_posix_path (/c/arc)
   16   3 [main] ls 28776 mount_info::conv_to_win32_path: 
conv_to_win32_path (/c/arc)
   14   30014 [main] ls 28776 mount_info::cygdrive_win32_path: src '/c/arc', 
dst 'C:\arc'
   13   30027 [main] ls 28776 set_flags: flags: binary (0x2)
   13   30040 [main] ls 28776 mount_info::conv_to_win32_path: src_path /c/arc, 
dst C:\arc, flags 0x6022, rc 0
   38   30078 [main] ls 28776 symlink_info::check: 0x0 = NtCreateFile 
(\??\C:\arc)
   38   30116 [main] ls 28776 symlink_info::check: 28 = symlink.check(C:\arc, 
0x22B600) (0x4406023)
   15   30131 [main] ls 28776 path_conv::check: this->path(C:\arc), has_acls(1)
   17   30148 [main] ls 28776 build_fh_pc: fh 0x180329B00, dev 00C3
   15   30163 [main] ls 28776 stat_worker: (\??\C:\arc, 0x60008A2F0, 
0x180329B00), file_attributes 1024
   19   30182 [main] ls 28776 fhandler_base::fstat_helper: 0 = fstat 
(\??\C:\arc, 0x60008A2F0) st_size=28, st_mode=0120777, 
st_ino=443041613342573138st_atim=54BC1392.15238F60 st_ctim=54BC1392.15238F60 
st_mtim=54BC1392.15238F60 st_birthtim=54BC1392.15238F60
   17   30199 [main] ls 28776 stat_worker: 0 = (\??\C:\arc,0x60008A2F0)
   37   30236 [main] ls 28776 normalize_posix_path: src /c/arc
   13   30249 [main] ls 28776 normalize_posix_path: /c/arc = 
normalize_posix_path (/c/arc)
   13   30262 [main] ls 28776 mount_info::conv_to_win32_path: 
conv_to_win32_path (/c/arc)
   14   30276 [main] ls 28776 mount_info::cygdrive_win32_path: src '/c/arc', 
dst 'C:\arc'
   13   30289 [main] ls 28776 set_flags: flags: binary (0x2)
   13   30302 [main] ls 28776 mount_info::conv_to_win32_path: src_path /c/arc, 
dst C:\arc, flags 0x6022, rc 0
   32   30334 [main] ls 28776 symlink_info::check: 0x0 = NtCreateFile 
(\??\C:\arc)
   37   30371 [main] ls 28776 symlink_info::check: 28 = symlink.check(C:\arc, 
0x22B570) (0x4006023)
   15   30386 [main] ls 28776 path_conv::check: 
this->path(//DAEMON1.DARKDRAGON.LAN/arc), has_acls(1)

On directory junction to another local drive:

 1825   26534 [main] ls 26712 lstat64: entering
   19   26553 [main] ls 26712 normalize_posix_path: src /c/Users
   14   26567 [main] ls 26712 normalize_posix_path: /c/Users = 
normalize_posix_path (/c/Users)
   14   26581 [main] ls 26712 mount_info::conv_to_win32_path: 
conv_to_win32_path (/c/Users)
   13   26594 [main] ls 26712 mount_info::cygdrive_win32_path: src '/c/Users', 
dst 'C:\Users'
   12   26606 [main] ls 26712 set_flags: flags: binary (0x2)
   12   26618 [main] ls 26712 mount_info::conv_to_win32_path: src_path 
/c/Users, dst C:\Users, flags 0x6022, rc 0
   45   26663 [main] ls 26712 symlink_info::check: 0x0 = NtCreateFile 
(\??\C:\Users)
  108   26771 [main] ls 26712 symlink_info::check: not a symlink
   20   26791 [main] ls 26712 symlink_info::check: 0 = symlink.check(C:\Users, 
0x22B600) (0x6022)
   14   26805 [main] ls 26712 path_conv::check: this->path(C:\Users), 
has_acls(1)
   16   26821 [main] ls 26712 build_fh_pc: fh 0x180329B00, dev 00C3
   14   26835 [main] ls 26712 stat_worker: (\??\C:\Users, 0x60008A2F0, 
0x180329B00), file_attributes 1072
   13   26848 [main] ls 26712 fhandler_base::open: (\??\C:\Users, 0x11)
   54   26902 [main] ls 26712 fhandler_base::set_flags: flags 0x11, 
supplied_bin 0x1
   15   26917 [main] ls 26712 fhandler_base::set_flags: O_TEXT/O_BINARY set in 
flags 0x1
   12   26929 [main] ls 26712 fhandler_base::set_flags: filemode set to binary
   12   26941 [main] ls 26712 fhandler_base::open: 0x0 = NtCreateFile (0x29C, 
0x8010, \??\C:\Users, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0)
   13   26954 [main] ls 26712 fhandler_base::open: 1 = 
fhandler_base::open(\??\C:\Users, 0x11)
   15   26969 [main] ls 26712 fhandler_base::open_fs: 1 = 
fhandler_disk_file::open(\??\C:\Users, 0x1)
   17   26986 [main] ls 26712 fhandler_base::fstat_helper: 0 = fstat 
(\??\C:\Users, 0x60008A2F0) st_size=0, st_mode=040755, 
st_ino=562949953508329st_atim=540F4952.1CDEF9D8 st_ctim=5405F6F7.8AFF78C 
st_mtim=5405F6F7.8AFF78C st_birthtim=53DFAC4D.59682F0
   14   27000 [main] ls 26712 fhandler_base::close: closing '/c/Users' handle 
0x29C
   20   27020 [main] ls 26712 stat_worker: 0 = (\??\C:\Users,0x60008A2F0)
   17   27037 [main] ls 26712 normalize_posix_path: src /c/Users
   12   27049 [main] ls 26712 normalize_posix_path: /c/Users = 
normalize_posix_path (/c/Users)
   12   27061 [main] ls 26712 

Updated: hwloc 1.11.1-1

[Marco Atzeri]

Version 1.11.1-1  of packages

  hwloc
  libhwloc-devel
  libhwloc5

are available in the Cygwin distribution:

CHANGES
Upstream bugfix release

Full upstream changes:
http://www.open-mpi.org/community/lists/hwloc-announce/2015/10/0080.php

DESCRIPTION
The Portable Hardware Locality (hwloc) software package provides a portable
abstraction (across OS, versions, architectures, ...) of the hierarchical
topology of modern architectures, including NUMA memory nodes, sockets,
shared caches, cores and simultaneous multithreading.

HOMEPAGE
http://www.open-mpi.org/projects/hwloc/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

[newlib-cygwin] Fix EIO error accessing certain (OS X SMB?) drives

[Corinna Vinschen]

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

commit 713161b28b85b7ce05c27a46c52b0780b96047ce
Author: Corinna Vinschen 
Date:   Wed Oct 21 12:01:11 2015 +0200

Fix EIO error accessing certain (OS X SMB?) drives

* path.cc (symlink_info::check_reparse_point): Don't generate an EIO
error if NtFsControlFile returns STATUS_NOT_A_REPARSE_POINT.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/ChangeLog | 5 +
 winsup/cygwin/path.cc   | 8 +++-
 winsup/cygwin/release/2.3.0 | 3 +++
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 59c7ca1..5d2675d 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,8 @@
+2015-10-21  Corinna Vinschen  
+
+   * path.cc (symlink_info::check_reparse_point): Don't generate an EIO
+   error if NtFsControlFile returns STATUS_NOT_A_REPARSE_POINT.
+
 2015-09-23  Evgeny Grin  
 
* fhandler_socket.cc (fhandler_socket::wait_for_events): Fix compiler
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 89dbdab..488d4e6 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2289,7 +2289,13 @@ symlink_info::check_reparse_point (HANDLE h, bool remote)
 {
   debug_printf ("NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, %y",
status);
-  set_error (EIO);
+  /* When accessing the root dir of some remote drives (observed with
+OS X shares), the FILE_ATTRIBUTE_REPARSE_POINT flag is set, but
+the followup call to NtFsControlFile(FSCTL_GET_REPARSE_POINT)
+returns with STATUS_NOT_A_REPARSE_POINT.  That's quite buggy, but
+we cope here with this scenario by not setting an error code. */
+  if (status != STATUS_NOT_A_REPARSE_POINT)
+   set_error (EIO);
   return 0;
 }
   if (rp->ReparseTag == IO_REPARSE_TAG_SYMLINK)
diff --git a/winsup/cygwin/release/2.3.0 b/winsup/cygwin/release/2.3.0
index 2f3adec..f2391a9 100644
--- a/winsup/cygwin/release/2.3.0
+++ b/winsup/cygwin/release/2.3.0
@@ -36,3 +36,6 @@ Bug Fixes
 - Fix a potential crash in advisory file locking due to usage of stack space
   out of scope.
   Addresses: https://cygwin.com/ml/cygwin/2015-09/msg00079.html
+
+- Fix EIO error accessing certain (OS X SMB?) drives
+  Addresses: https://cygwin.com/ml/cygwin/2015-09/msg00229.html

[ANNOUNCEMENT] Updated: pugixml-1.7-1

[David Stacey]

The following packages have been updated in the Cygwin distribution:

* libpugixml1-1.7-1
* libpugixml-devel-1.7-1
* pugixml-doc-1.7-1

pugixml is a lightweight C++ XML processing library.

This is an update to the latest upstream release.

Dave.

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

[ANNOUNCEMENT] Updated: hwloc 1.11.1-1

[Marco Atzeri]

Version 1.11.1-1  of packages

  hwloc
  libhwloc-devel
  libhwloc5

are available in the Cygwin distribution:

CHANGES
Upstream bugfix release

Full upstream changes:
http://www.open-mpi.org/community/lists/hwloc-announce/2015/10/0080.php

DESCRIPTION
The Portable Hardware Locality (hwloc) software package provides a portable
abstraction (across OS, versions, architectures, ...) of the hierarchical
topology of modern architectures, including NUMA memory nodes, sockets,
shared caches, cores and simultaneous multithreading.

HOMEPAGE
http://www.open-mpi.org/projects/hwloc/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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

Updated: pugixml-1.7-1

[David Stacey]

The following packages have been updated in the Cygwin distribution:

* libpugixml1-1.7-1
* libpugixml-devel-1.7-1
* pugixml-doc-1.7-1

pugixml is a lightweight C++ XML processing library.

This is an update to the latest upstream release.

Dave.

Updated: libmatroska-1.4.4-1

[David Stacey]

The following packages have been updated in the Cygwin distribution:

* libmatroska6-1.4.4-1
* libmatroska-devel-1.4.4-1

libmatroska is a C++ library to parse Matroska files (*.mkv, *.mka).

This is an update to the latest upstream release.

Dave.

[ANNOUNCEMENT] [SECURITY] Updated: libebml-1.3.3-1

[David Stacey]

The following packages have been updated in the Cygwin distribution:

* libebml4-1.3.3-1
* libebml-devel-1.3.3-1

libebml is a library for reading and writing files with the Extensible
Binary Meta Language, a binary pendant to XML.

This is an update to the latest upstream release.

This release addresses two security vulnerabilities, classified as
TALOS-CAN-0036 and TALOS-CAN-0037. Once disclosed publicly, details
will be available here: http://talosintel.com/vulnerability-reports/

Dave.

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

[ANNOUNCEMENT] Updated: libmatroska-1.4.4-1

[David Stacey]

The following packages have been updated in the Cygwin distribution:

* libmatroska6-1.4.4-1
* libmatroska-devel-1.4.4-1

libmatroska is a C++ library to parse Matroska files (*.mkv, *.mka).

This is an update to the latest upstream release.

Dave.

--
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: Error accessing mapped drive >2TB?

[Corinna Vinschen]

On Sep 14 14:34, Warren Young wrote:
> On Sep 12, 2015, at 11:14 AM, Nem W Schlecht  wrote:
> > 
> > The only thing I can think of is that the 2nd drive is >2TB.
> 
> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external 
> drive, so no, I don’t think the volume size is the real issue.
> 
> I assume you are seeing the same thing that I am, that Explorer shows the 
> root contents of both drives just fine?
> 
> When I strace’d an ls of one of these root shares here, I got 764 lines 
> of…emissions, of which this section seems the most interesting to me:
> 
> 1051  263166 [main] ls 4720 stat64: entering
>   625  263791 [main] ls 4720 normalize_posix_path: src /p
>   609  264400 [main] ls 4720 normalize_posix_path: /p = normalize_posix_path 
> (/p)
>   630  265030 [main] ls 4720 mount_info::conv_to_win32_path: 
> conv_to_win32_path (/p)
>   653  265683 [main] ls 4720 mount_info::cygdrive_win32_path: src '/p', dst 
> 'P:\'
>   668  266351 [main] ls 4720 set_flags: flags: binary (0x2)
>   674  267025 [main] ls 4720 mount_info::conv_to_win32_path: src_path /p, dst 
> P:\, flags 0x4022, rc 0
>  1168  268193 [main] ls 4720 symlink_info::check: 0x0 = NtCreateFile (\??\P:\)
> 10641  278834 [main] ls 4720 symlink_info::check_reparse_point: 
> NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, 0xC275
>   839  279673 [main] ls 4720 symlink_info::check: not a symlink
>  1049  280722 [main] ls 4720 symlink_info::check: 0 = symlink.check(P:\, 
> 0x24B620) (0x4022)
>   655  281377 [main] ls 4720 path_conv::check: this->path(P:\), has_acls(0)
>   640  282017 [main] ls 4720 stat_worker: got 5 error from path_conv
>   757  282774 [main] ls 4720 __set_errno: int stat_worker(path_conv&, 
> stat*):1933 setting errno 5
>   714  283488 [main] ls 4720 stat_worker: -1 = (\??\P:\,0x600042080)
> 
> Why errno 5 from path_conv?

Probably because of the above

  symlink_info::check_reparse_point: NtFsControlFile(FSCTL_GET_REPARSE_POINT)
  failed, 0xC275

This is in fact a weird error code in this scenario.

Consider that symlink_info::check_reparse_point is *only* called, if the
file to check (here "P:\") has the FILE_ATTRIBUTE_REPARSE_POINT flag
set.  So from the Windows perspective it is certainly a reparse point.

Cygwin checks the flag to allow evaluating of reparse points as symlinks.
If the flag is set, it calls symlink_info::check_reparse_point which in
turn calls

  status = NtFsControlFile (..., FSCTL_GET_REPARSE_POINT, ...);

to fetch the target information the reparse point points to, in POSIX
terms the symlink target.  But *this* call returns a status of 0xC275,
which means STATUS_NOT_A_REPARSE_POINT.  And since it's totally unexpected
that NtFsControlFile fails on a reparse point, the code sets errno to EIO.

Hang on.

The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
to fetch the reparse data it's no reparse point anymore?  How dumb is
that?

I can't reproduce this bug with my Samba drives, but it's not actually a
bug in Cygwin from my perspective.

Yeah, that observation doesn't really help, so I applied a potential
workaround to Cygwin.  If you're set up to build your own Cygwin, please
give it a try.  Otherwise I'll upload a new snapshot in the next couple of
days.


Thanks,
Corinna

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


pgpChY3LL4nd1.pgp
Description: PGP signature

Re: gawk 4.1.3: warning: gensub: third argument

[Corinna Vinschen]

On Oct  3 04:59, Westlund, John A wrote:
> I first noticed this issue after an update to gawk 4.1.3. If the third 
> argument in a call to gensub is bogus a warning is generated where is used to 
> silently pass through:
> 
> $ echo asdf  | gawk '{print gensub(/a/,"b","")}'
> gawk: cmd. line:1: (FILENAME=- FNR=1) warning: gensub: third argument `' 
> treated as 1
> bsdf
> $ gawk -V
> GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.3, GNU MP 6.0.0)
> Copyright (C) 1989, 1991-2015 Free Software Foundation.
> 
> On other gawk versions this is the behavior:
> $ echo asdf | gawk '{print gensub(/a/,"b","")}'
> Bsdf
> 
> Appears to be resolved by this patch:
> https://www.sourceware.org/ml/libc-alpha/2015-08/msg00269.html

No, that's a patch in glibc to cope with the changed behaviour of gawk
4.1.3.  The upstream change was intentional.


Corinna

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


pgpXLBVNceyi6.pgp
Description: PGP signature

[newlib-cygwin] Fix memory leak in pthread_getattr_np

[Corinna Vinschen]

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

commit c0345822e502f45b412ab595e14c51dfdae5aaef
Author: Corinna Vinschen 
Date:   Wed Oct 21 12:46:32 2015 +0200

Fix memory leak in pthread_getattr_np

* thread.cc (pthread_getattr_np): Fix memory leak, remove usage of
malloc for small local buffer.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/ChangeLog | 5 +
 winsup/cygwin/release/2.3.0 | 2 ++
 winsup/cygwin/thread.cc | 8 +++-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 5d2675d..4cbbd0b 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,5 +1,10 @@
 2015-10-21  Corinna Vinschen  
 
+   * thread.cc (pthread_getattr_np): Fix memory leak, remove usage of
+   malloc for small local buffer.
+
+2015-10-21  Corinna Vinschen  
+
* path.cc (symlink_info::check_reparse_point): Don't generate an EIO
error if NtFsControlFile returns STATUS_NOT_A_REPARSE_POINT.
 
diff --git a/winsup/cygwin/release/2.3.0 b/winsup/cygwin/release/2.3.0
index f2391a9..d6fda3b 100644
--- a/winsup/cygwin/release/2.3.0
+++ b/winsup/cygwin/release/2.3.0
@@ -39,3 +39,5 @@ Bug Fixes
 
 - Fix EIO error accessing certain (OS X SMB?) drives
   Addresses: https://cygwin.com/ml/cygwin/2015-09/msg00229.html
+
+- Fix memory leak in calls to pthread_getattr_np.
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index b92a806..d9b6211 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -2485,8 +2485,7 @@ pthread::resume (pthread_t *thread)
 extern "C" int
 pthread_getattr_np (pthread_t thread, pthread_attr_t *attr)
 {
-  const size_t sizeof_tbi = sizeof (THREAD_BASIC_INFORMATION);
-  PTHREAD_BASIC_INFORMATION tbi;
+  THREAD_BASIC_INFORMATION tbi;
   NTSTATUS status;
 
   if (!pthread::is_good_object ())
@@ -2506,13 +2505,12 @@ pthread_getattr_np (pthread_t thread, pthread_attr_t 
*attr)
   (*attr)->schedparam = thread->attr.schedparam;
   (*attr)->guardsize = thread->attr.guardsize;
 
-  tbi = (PTHREAD_BASIC_INFORMATION) malloc (sizeof_tbi);
   status = NtQueryInformationThread (thread->win32_obj_id,
 ThreadBasicInformation,
-tbi, sizeof_tbi, NULL);
+, sizeof (tbi), NULL);
   if (NT_SUCCESS (status))
 {
-  PTEB teb = (PTEB) tbi->TebBaseAddress;
+  PTEB teb = (PTEB) tbi.TebBaseAddress;
   /* stackaddr holds the uppermost stack address.  See the comments
 in pthread_attr_setstack and pthread_attr_setstackaddr for a
 description. */

Re: Jemalloc under CYGWIN

[Corinna Vinschen]

On Oct 16 23:56, Yucong Sun wrote:
> Hi,
> 
> Throught some frustrating and furious debugging I now understand the
> core issue here.  CYGWIN calls malloc provided by jemalloc during
> initializations,  which in turn calls pthreads functions, which in
> turn uses malloc, which also uses pthreads, causing a deadlock.
> 
> Now,  is there anyway to workaround this issue?

Not quickly, at least.  I looked into thread.cc and pthread.cc and
only found two uses of malloc, one of them should only occur when
pthread_exit'ing the main thread, the other in pthread_getattr_np.
The first shouldn't matter to jemalloc (or, does it?), the second
one I just eliminated.

What exactly is the malloc problem you're seeing?

In the long run it would be very nice if we could get jemalloc working
as the default malloc implementation in Cygwin, replacing dlmalloc.
This would allow to get rid of the slow global locking in malloc_wrapper.cc.

Historical note: At one point I tried to integrate ptmalloc3, but it
always had some unwanted side-effects and fixing them would have been
very complicated at the time.


So, if you're looking into getting jemalloc into Cygwin, feel free
to discuss this further on the cygwin-developers mailing list.


Thanks,
Corinna

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


pgp0fXZIIdhS0.pgp
Description: PGP signature

New package: nccmp-1.7.5.1-1

[Remik Ziemlinski]

Version 1.7.5.1-1 of "nccmp" has been uploaded.

nccmp compares two NetCDF files bitwise, semantically or
with a user defined tolerance (absolute or relative
percentage). Parallel comparisons are done in local memory
without requiring temporary files. Highly recommended for
regression testing scientific models or datasets in a
test-driven development environment.

http://nccmp.sourceforge.net/

Remik

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.

[ANNOUNCEMENT] New package: nccmp-1.7.5.1-1

[Remik Ziemlinski]

Version 1.7.5.1-1 of "nccmp" has been uploaded.

nccmp compares two NetCDF files bitwise, semantically or
with a user defined tolerance (absolute or relative
percentage). Parallel comparisons are done in local memory
without requiring temporary files. Highly recommended for
regression testing scientific models or datasets in a
test-driven development environment.

http://nccmp.sourceforge.net/

Remik

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.


--
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 1.4 bug(?) - "Bash Prompt Here" not shown under Libraries folders

[cpengr]

Under certain circumstances, when I right-click in the empty space in
Windows Explorer, in any folder or subfolder beneath any "Libraries"
folder (e.g. my "Documents"), the "Bash Prompt Here" option is not
shown in the context menu.

Option is *not shown* under these circumstances:

1. Browse to the folder/subfolder via the Libraries tree on the left
pane in Windows Explorer. (Including after drilling down via the right
side by double clicking.)

2. After #1, even if I copy the path from the explorer bar, and paste
it back in to the same, and press Enter.

However, the option *is* shown under the following circumstances:

3. Folders/subfolders not under Libraries.

4. Browse to the folder from the absolute path. (i.e. Via drive
letter, folder, subfolder...not via Libraries.)

5. Right-click on the folders/subfolders themselves (not on empty
space inside them), even if browing to them via Libraries.

6. Browse to folder under Libraries in Explorer via the Libraries
listed on the left. Copy the path from the location bar, paste it into
a *new explorer window*. Right click in the empty space within the
folder.

`which chere` tells me it's version 1.4. I'm running Cygwin x64 on
Win7 x64 w/ SP1. Redacted cygcheck.out attached.

cpengr


cygcheck.out
Description: Binary data
--
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: Error accessing mapped drive >2TB?

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > The only thing I can think of is that the 2nd drive is >2TB.
>> 
>> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external 
>> drive, so no, I don’t think the volume size is the real issue.
>> 
>> I assume you are seeing the same thing that I am, that Explorer shows the 
>> root contents of both drives just fine?
>> 
>> When I strace’d an ls of one of these root shares here, I got 764 lines 
>> of…emissions, of which this section seems the most interesting to me:
>> 
>> 1051  263166 [main] ls 4720 stat64: entering
>>   625  263791 [main] ls 4720 normalize_posix_path: src /p
>>   609  264400 [main] ls 4720 normalize_posix_path: /p = normalize_posix_path 
>> (/p)
>>   630  265030 [main] ls 4720 mount_info::conv_to_win32_path: 
>> conv_to_win32_path (/p)
>>   653  265683 [main] ls 4720 mount_info::cygdrive_win32_path: src '/p', dst 
>> 'P:\'
>>   668  266351 [main] ls 4720 set_flags: flags: binary (0x2)
>>   674  267025 [main] ls 4720 mount_info::conv_to_win32_path: src_path /p, 
>> dst P:\, flags 0x4022, rc 0
>>  1168  268193 [main] ls 4720 symlink_info::check: 0x0 = NtCreateFile 
>> (\??\P:\)
>> 10641  278834 [main] ls 4720 symlink_info::check_reparse_point: 
>> NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, 0xC275
>>   839  279673 [main] ls 4720 symlink_info::check: not a symlink
>>  1049  280722 [main] ls 4720 symlink_info::check: 0 = symlink.check(P:\, 
>> 0x24B620) (0x4022)
>>   655  281377 [main] ls 4720 path_conv::check: this->path(P:\), has_acls(0)
>>   640  282017 [main] ls 4720 stat_worker: got 5 error from path_conv
>>   757  282774 [main] ls 4720 __set_errno: int stat_worker(path_conv&, 
>> stat*):1933 setting errno 5
>>   714  283488 [main] ls 4720 stat_worker: -1 = (\??\P:\,0x600042080)
>> 
>> Why errno 5 from path_conv?

> Probably because of the above

>   symlink_info::check_reparse_point: NtFsControlFile(FSCTL_GET_REPARSE_POINT)
>   failed, 0xC275

> This is in fact a weird error code in this scenario.

> Consider that symlink_info::check_reparse_point is *only* called, if the
> file to check (here "P:\") has the FILE_ATTRIBUTE_REPARSE_POINT flag
> set.  So from the Windows perspective it is certainly a reparse point.

> Cygwin checks the flag to allow evaluating of reparse points as symlinks.
> If the flag is set, it calls symlink_info::check_reparse_point which in
> turn calls

>   status = NtFsControlFile (..., FSCTL_GET_REPARSE_POINT, ...);

> to fetch the target information the reparse point points to, in POSIX
> terms the symlink target.  But *this* call returns a status of 0xC275,
> which means STATUS_NOT_A_REPARSE_POINT.  And since it's totally unexpected
> that NtFsControlFile fails on a reparse point, the code sets errno to EIO.

> Hang on.

> The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
> to fetch the reparse data it's no reparse point anymore?  How dumb is
> that?

That's… interesting.
Windows does not allow for reparse points to networked locations.
Symlinks all right, directory junctions no.

> I can't reproduce this bug with my Samba drives, but it's not actually a
> bug in Cygwin from my perspective.

> Yeah, that observation doesn't really help, so I applied a potential
> workaround to Cygwin.  If you're set up to build your own Cygwin, please
> give it a try.  Otherwise I'll upload a new snapshot in the next couple of
> days.


-- 
With best regards,
Andrey Repin
Wednesday, October 21, 2015 15:32:13

Sorry for my terrible english...

Re: Error accessing mapped drive >2TB?

[Corinna Vinschen]

On Oct 21 15:33, Andrey Repin wrote:
> Greetings, Corinna Vinschen!

Your mailer is breaking the history, btw.  Could you reconfigure so the
"blah wrote:" header is preserved for each mail in the thread you still
quote?  Thanks.

> > Probably because of the above
> 
> >   symlink_info::check_reparse_point: 
> > NtFsControlFile(FSCTL_GET_REPARSE_POINT)
> >   failed, 0xC275
> 
> > This is in fact a weird error code in this scenario.
> 
> > Consider that symlink_info::check_reparse_point is *only* called, if the
> > file to check (here "P:\") has the FILE_ATTRIBUTE_REPARSE_POINT flag
> > set.  So from the Windows perspective it is certainly a reparse point.
> 
> > Cygwin checks the flag to allow evaluating of reparse points as symlinks.
> > If the flag is set, it calls symlink_info::check_reparse_point which in
> > turn calls
> 
> >   status = NtFsControlFile (..., FSCTL_GET_REPARSE_POINT, ...);
> 
> > to fetch the target information the reparse point points to, in POSIX
> > terms the symlink target.  But *this* call returns a status of 0xC275,
> > which means STATUS_NOT_A_REPARSE_POINT.  And since it's totally unexpected
> > that NtFsControlFile fails on a reparse point, the code sets errno to EIO.
> 
> > Hang on.
> 
> > The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
> > to fetch the reparse data it's no reparse point anymore?  How dumb is
> > that?
> 
> That's… interesting.
> Windows does not allow for reparse points to networked locations.
> Symlinks all right, directory junctions no.

Fine, but then the question is, why is the FILE_ATTRIBUTE_REPARSE_POINT
flag set in the first place?


Corinna

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


pgpgXlvB7H26r.pgp
Description: PGP signature

Re: Bad Address with /cygdrive paths

[Corinna Vinschen]

On Oct 12 18:59, Barry Roberts wrote:
> I've used cygwin for lots of years, and this is kind of weird to me.
> My operations guys set up some Windows Server 2012 R2 servers with
> Cygwin x86-64 2.2.1.
> 
> There's a CIFS mount (from an HNAS) that I use a lot that is giving me
> problems.  For example:
> 
> $ ls /cygdrive/m/install
> ls: cannot access /cygdrive/m/install: Bad address

Would you mind to run strace in this scenario:

  $ strace -o ls.trace ls /cygdrive/m/install

and attach the ls.trace file here?

> 
> But:
> $ ls m:/install
> 
> Works just great.
> 
> Using /cygdrive/m I can list the contents of the root of the drive,
> but I can't read any files.  And any subdirectory just gives me the
> "Bad address" error.   Everything (except completion) works just fine
> with m:/ paths.
> 
> This isn't a huge deal.  I mostly use cygwin on these servers to
> manage them with scripts, so I've changed my configuration variables
> to : paths and everything seems to work.  But I did
> spend nearly half a day figuring this out, so I'm curious if there's a
> configuration problem or a known issue that my searches haven't
> uncovered yet.

Nothing I'd be aware of.


Thanks,
Corinna

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


pgpBgV5QCptgC.pgp
Description: PGP signature

Re: pthread_kill: signals remain pending after target thread exits

[Corinna Vinschen]

Hi John,

On Sep 11 18:11, John Carey wrote:
> There seems to be a problem with pthread_kill: a pending signal
> targeting a particular thread prevents other threads from receiving
> signals sharing the same signal number--even after the original target
> thread exits and is joined.
> 
> To reproduce the issue:
> 
>   1. Block signal number S.
> 
>   2. Create thread T.
> 
>   3. Send a signal with signal number S to thread T in particular (as
>   opposed to the process in general).
> 
>   4. After that signal has been sent, allow T to terminate without
>   unblocking S or calling sigwait().
> 
>   5. Join T.
> 
>   6. Create thread N.
> 
>   7. Have N call sigwait() with a signal set that contains S.
> 
>   8. Send to N a new signal with signal number S.
> 
>   9. N never receives the new signal--instead, the new signal is
>   discarded because the earlier signal remains pending.

Yuk.

> BUT: It seems possible that N might inadvertently inherit the pending
> signal if its _cygtls instance happens to be allocated at the same
> address as the _cygtls instance of T.  It would be hard to predict
> when that would happen.  See the discussion of the source code, below.

The important thing here is to get rid of the pending signal.

> For comparison, note that when performing the same steps on Linux
> (Ubuntu 14.04.3), N does in fact receive the second signal.
> 
> Here is the relevant Cygwin source code, if I am understanding things
> correctly:
> 
>   - sigproc.cc : wait_sig : calls pending_signals::add, then tries to
>   process signals in the queue, but leaves queued any signal that
>   failed to process
> 
>   - exceptions.cc : sigpacket::process : signal processing fails if it
>   cannot find the target thread using init_cygheap::find_tls
> 
>   - sigproc.cc : pending_signals::add : discards new signals whose
>   signal number matches that of a pending signal--regardless of target
>   thread
> 
>   - cygheap.cc : init_cygheap::find_tls : looks for a thread by the
>   address of its _cygtls instance, but a thread that has been joined
>   might happen to have had the same _cygtls address as a thread that
>   was subsequently created, and therefore pending signals for
>   terminated threads might sometimes be inherited by unrelated new
>   threads (or so it seems to me--as yet I have not managed to trigger
>   such a scenario)
> 
> In my view it would be desirable if:
> 
>   - Pending signals targeting a particular thread would not outlast
>   that thread.

Since you looked into the code anyway, do you have an idea how to
implement that?  For a start, do you have a simple testcase, only
the bare code needed to reproduce the issue?

>   - Multiple pending signals targeting different threads could
>   coexist, even if they shared the same signal number.  This happens
>   on Linux (Ubuntu 14.04.3), where I can generate two signals for two
>   different threads, then sleep for a bit in each target thread, and
>   finally have each thread receive its signal with sigwait()--neither
>   signal is lost during the sleeping period.

That requires to extend the handling for pending signals.  That's
a rather bigger task...


Corinna

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


pgpxsEL9mtJXL.pgp
Description: PGP signature

Re: fstat st_size on open files on Parallels filesystem is wrong

[Corinna Vinschen]

On Oct  8 12:16, Jonathan Lennox wrote:
> Hi, following up on this issue from last year.  The message I'm replying to
> is at .
> 
> The problem is weird behavior in Parallels Desktop-hosted Windows VMs, when
> accessing the host's native Mac OS X filesystem.  See the thread for the
> details.
> 
> On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
> saying:
> 
> > > At this point this is looking pretty clearly like a Parallels Tools bug.
> > > I'll report it to them.
> > 
> > Yes, that sounds good.  Given that, I'm wondering if we should try to
> > workaround this problem at all or rather wait to see if the vendor will
> > fix the issue.
> 
> No such luck, despite two major version revisions of Parallels Desktop (I'm
> now on version 11.0.2) and moving to Windows 10 as the guest OS -- the bug
> perists, unchanged.  So it looks like Cygwin will need to add a workaround
> for this filesystem to fix the problem.

Ok, we could do that.  Can you compile and run the testcase from
https://cygwin.com/ml/cygwin/2014-04/msg00523.html again?  Does it
still show 0 vs. 12 bytes?  Dumb extra test: Does the output change
if you reorder the calls, requesting FileStandardInformation first,
FileNetworkOpenInformation second?

> The output of /usr/lib/csih/getVolInfo seems to be unchanged from the output
> I reported last year.
> 
> > Thanks.  This looks pretty much like a filesystem pretending to be
> > FAT-like.  There may be another problem lurking, which is, are the inode
> > numbers (called "FileId" or "IndexNumber" in Windows) persistant?  With
> > FAT this is not the case, and given the above, it might be a problem...
> > 
> > ...or not.  I just realize that Cygwin doesn't even try to use the
> > FileId as inode number on filesystems with FILE_PERSISTENT_ACLS==FALSE
> > so, never mind.
> > 
> > OTOH, does it support hardlinks?  If so, two hardlinks to the
> > same file would have different inode numbers on Cygwin.
> 
> How would I figure these points out?

Just create a hardlink on that drive using native means:

  $ touch foo
  $ cmd /c mklink /h bar foo

Error at this point?  No hardlinks.  Otherwise:

  $ ls -li foo bar

Are the inode numbers identical?  Congrats, hardlinks work.  But given
the general FAT-iness of the getVolInfo output, I guess it doesn't
maintain hardlinks.


Corinna

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


pgpWqDZk65Ta9.pgp
Description: PGP signature

[newlib-cygwin] * winsup/doc/faq-using.xml (faq.using.same-with-permissions): New entry.

[Corinna Vinschen]

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

commit 215dbf05fe1d8164280d669f6ccdc081085943bb
Author: Ken Brown 
Date:   Tue Oct 6 16:31:05 2015 -0400

* winsup/doc/faq-using.xml (faq.using.same-with-permissions): New entry.

Diff:
---
 winsup/doc/ChangeLog |  4 
 winsup/doc/faq-using.xml | 42 ++
 2 files changed, 46 insertions(+)

diff --git a/winsup/doc/ChangeLog b/winsup/doc/ChangeLog
index 35935be..7e85a76 100644
--- a/winsup/doc/ChangeLog
+++ b/winsup/doc/ChangeLog
@@ -1,3 +1,7 @@
+2015-10-06  Ken Brown  
+
+   * faq-using.xml (faq.using.same-with-permissions): New entry.
+
 2015-09-07  Brian Inglis  
 
* faq-using.xml (faq.using.man): Replace makewhatis with mandb.
diff --git a/winsup/doc/faq-using.xml b/winsup/doc/faq-using.xml
index 7656880..4cfc822 100644
--- a/winsup/doc/faq-using.xml
+++ b/winsup/doc/faq-using.xml
@@ -1183,6 +1183,48 @@ Users group instead.
 
 
 
+
+Why do my files have extra permissions after updating to 
Cygwin 1.7.34?
+
+
+The problem is exactly the same as with the key files of SSH.  See
+.
+
+The solution is the same:
+
+
+  $ ls -l *
+  -rw-rwxr--+ 1 user group 42 Nov 12  2010 file1
+  -rw-rwxr--+ 1 user group 42 Nov 12  2010 file2
+  $ setfacl -b *
+  $ ls -l *
+  -rw-r--r--  1 user group 42 Nov 12  2010 file1
+  -rw-r--r--  1 user group 42 Nov 12  2010 file2
+
+
+You may find that newly-created files also have unexpected
+permissions:
+
+
+  $ touch foo
+  $ ls -l foo
+  -rw-rwxr--+ 1 user group 42 Nov 12  2010 foo
+
+
+This probably means that the directory in which you're creating
+the files has unwanted default ACL entries that are inherited by
+newly-created files and subdirectories.  The solution is again the
+same:
+
+
+  $ setfacl -b .
+  $ touch bar
+  $ ls -l bar
+  -rw-r--r--  1 user group 42 Nov 12  2010 bar
+
+
+
+
 
 Why do my Tk programs not work anymore?
 

Re: [OT] Wine + Cygwin: `script -e` exit status forwarding randomly return zero for non zero child process

[Corinna Vinschen]

On Oct 21 12:50, Qian Hong wrote:
> Update:
> 
> The script exit status issue is fixed in the Wine side in Wine Staging
> 1.7.53, patch commited as
> https://github.com/wine-compholio/wine-staging/commit/be51f622f7ed5a4f558bc54743314b310727ac4d
> 
> (OT of OT: In WineConf2015, upstream WineHQ formally announced Wine
> Staging become parts of official Wine, I'd encourage any user who is
> interesting in using Cygwin on Wine to try Wine Staging. Cheers!)
> 
> Thanks for the previous great support to help us understand and fix
> this bug! (As always :P)

Thanks for letting us know!


Corinna

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


pgpYRm7wIuRmH.pgp
Description: PGP signature

Re: Proposal to use ThreadQuerySetWin32StartAddress inside munge_threadfunc (Cygwin randomly crashes on Wine)

[Corinna Vinschen]

Hi Qian,

On Oct  2 21:27, Qian Hong wrote:
> Dear Cygwin developers,
> 
> While testing Cygwin on Wine, there is a random crashing puzzled me
> for a wrong time.
> [...]
> Alternative, we also tried a hack in the Cygwin side, which use
> ThreadQuerySetWin32StartAddress to query the thread entry point, as
> 0001-hack-use-ThreadQuerySetWin32StartAddress.txt show. I tested this
> hack with recent Cygwin git repo and confirming it works for me
> (without hack from Wine side). I also tested my own cygwin build with
> this hack on Windows to confirm it doesn't break things.
> 
> Is the proposal way accepted by Cygwin? I understand we hate changing
> working code (on Windows), but using ThreadQuerySetWin32StartAddress
> seems like an improvement than rely on searching result from stack
> memory. If we could discuss a solution which makes both Cygwin and
> Wine happy that would be great.
> 
> MSDN says, "Note that on versions of Windows prior to Windows Vista,
> the returned start address is only reliable before the thread starts
> running.". Actually I tested my build on Windows XP sp2 and it works
> for me. Additional, since Cygwin is moving to the end of Windows XP
> support, maybe we are at the right time to do this change.

Thanks for this patch.  I tried it on Windows 10 under 64 bit and it
works fine, too.  While the existing code seems to work on Windows as
desired, it's not really a safe bet, so calling NtQueryInformationThread
to get the correct thread start address seems like a nice improvement.

Sidenote: During testing it occured to me that it would be even better
if we could just call NtSetInformationThread setting the entry point to
threadfunc_fe dropping the rather hackish stack walk entirely.  Alas,
apparently this functionality, calling NtSetInformationThread with the
ThreadQuerySetWin32StartAddress information class, has been
intentionally broken starting with Windows Vista :-P

I simplified your patch, taking out the printf's and added a test in the
loop in case NtQueryInformationThread failed.  See below.  It's not
overly large, but it introduces new functionality.  It would be nice if
you could sign a copyright assignment and send it as PDF.  Please see
https://cygwin.com/assign.txt.


Thanks,
Corinna


diff --git a/winsup/cygwin/init.cc b/winsup/cygwin/init.cc
index 56d4668..69e66a0 100644
--- a/winsup/cygwin/init.cc
+++ b/winsup/cygwin/init.cc
@@ -55,12 +55,17 @@ munge_threadfunc ()
 
   if (threadfunc_ix[0])
 {
-  char *threadfunc = ebp[threadfunc_ix[0]];
+  char *threadfunc = NULL;
+
+  NtQueryInformationThread (NtCurrentThread (),
+   ThreadQuerySetWin32StartAddress,
+   , sizeof threadfunc, NULL);
   if (!search_for || threadfunc == search_for)
{
  search_for = NULL;
  for (i = 0; threadfunc_ix[i]; i++)
-   ebp[threadfunc_ix[i]] = (char *) threadfunc_fe;
+   if (!threadfunc || ebp[threadfunc_ix[i]] == threadfunc)
+  ebp[threadfunc_ix[i]] = (char *) threadfunc_fe;
  TlsSetValue (_my_oldfunc, threadfunc);
}
 }
diff --git a/winsup/cygwin/ntdll.h b/winsup/cygwin/ntdll.h
index 13a131d..050e848 100644
--- a/winsup/cygwin/ntdll.h
+++ b/winsup/cygwin/ntdll.h
@@ -1162,7 +1162,8 @@ typedef enum _THREADINFOCLASS
 {
   ThreadBasicInformation = 0,
   ThreadTimes = 1,
-  ThreadImpersonationToken = 5
+  ThreadImpersonationToken = 5,
+  ThreadQuerySetWin32StartAddress = 9
 } THREADINFOCLASS, *PTHREADINFOCLASS;
 
 /* Checked on 64 bit. */

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


pgpexLwZdH2uB.pgp
Description: PGP signature

Re: New FAQ entry about permissions since Cygwin 1.7.34

[Corinna Vinschen]

On Oct 20 18:48, Ken Brown wrote:
> On 10/20/2015 3:25 PM, Corinna Vinschen wrote:
> >Hi Ken,
> >
> >On Oct  6 16:41, Ken Brown wrote:
> >>There have been several recent threads on the cygwin list stemming from the
> >>permissions change in 1.7.34.  I've pointed people to the FAQ about ssh
> >>public key authentication, which is not the first place where someone with
> >>this problem is likely to look.  The following patch attempts to remedy
> >>this:
> >
> >Unfortunately it doesn't apply cleanly.  There are weird differences in
> >whitespaces and a patch-breaking line wrap.  Can you check and resend,
> >please?
> 
> Sorry, my mailer must have messed it up.  Here it is as an attachment.

Thanks, applied.


Corinna

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


pgpAViR6z2hCv.pgp
Description: PGP signature