[ANNOUNCEMENT] python-pygments, python3-pygments 2.0.2-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* python-pygments-2.0.2-1
* python3-pygments-2.0.2-1

Pygments is a syntax highlighting package written in Python. It is a 
generic syntax highlighter for general use in all kinds of software such 
as forum systems, wikis or other applications that need to prettify 
source code.

This is an update to the latest upstream release, with a patch for a 
shell injection vulnerability:

https://bugzilla.redhat.com/show_bug.cgi?id=1276321

--
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] gthumb 3.2.9.1-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gthumb-3.2.9.1-2
* gthumb-devel-3.2.9.1-2

gThumb is a powerful image browser, viewer, organizer, and editor for 
the GNOME Desktop.

--
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] gnome-commander 1.4.7-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gnome-commander-1.4.7-1

GNOME Commander is a two-pane graphical filemanager for the GNOME 
desktop environment. GNOME Commander aims to fulfill the demands of more 
advanced users who like to focus on file management, their work through 
special applications and running smart commands.

--
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] mesa 11.0.4-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* mesa-11.0.4-1
* dri-drivers-11.0.4-1
* libglapi0-11.0.4-1
* libGL1-11.0.4-1
* libGL-devel-11.0.4-1
* libOSMesa8-11.0.4-1
* libOSMesa-devel-11.0.4-1
* libEGL1-11.0.4-1
* libEGL-devel-11.0.4-1
* libGLESv2_2-11.0.4-1
* libGLESv2-devel-11.0.4-1
* windowsdriproto-11.0.4-1

Mesa is an open-source implementation of the OpenGL specification,
a system for rendering interactive 3D graphics.

Complete documentation on OpenGL usage and configuration can be found here:

http://x.cygwin.com/docs/ug/using-glx.html

This is an update to the latest upstream bugfix release:

http://mesa3d.org/relnotes/11.0.4.html

--
Yaakov

--
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] krename 4.0.9-6

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* krename-4.0.9-6

KRename is a powerful batch renamer for KDE. It allows you to easily 
rename hundreds or even more files in one go. The filenames can be 
created by parts of the original filename, numbering the files or 
accessing hundreds of informations about the file, like creation date or 
Exif informations of an image.

--
Yaakov


--
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] gmic 1.6.7-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gmic-1.6.7-1
* gmic-zart-1.6.7-1
* gimp-gmic-1.6.7-1
* libgmic1-1.6.7-1
* libgmic-devel-1.6.7-1

G'MIC is focused on the design of complex pipelines for converting, 
manipulating, filtering and visualizing generic 1d/2d/3d multi-spectral 
image datasets. Of course, it is able to manage color images, but also 
more complex data as image sequences or 3d volumetric datasets.

--
Yaakov

--
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: Help: cygheap base mismatch detected

[Jim Reisert AD1C]

On Mon, Nov 2, 2015 at 4:31 AM, Corinna Vinschen wrote:

> It seems a Windows DLL or a virus scanner DLL gets loaded to this
> address for some reason.  I'm a bit at a loss to make a suggestion here,
> except for switching to 64 bit Cygwin which has much less problems with
> this due to the huge address space.

I meant to reply to this earlier today, but lines between day/night
and work/not have been too blurry lately.

I tried a clean install of 32-bit Cygwin, but that didn't fix
anything.  So then on a lark, I rebooted the computer (turned it off
actually, which I have not done in weeks), and magically, the problem
went away.  Maybe Windows 10 had its knickers in a twist or something,
but everything else seemed to run just fine, except Cygwin.

I have tried 64-bit Cygwin in the past.  I do a lot of file I/O and
sorting/searching on largish test-based data sets, and 64-bit was
noticeably slower than 32-bit Cygwin, so I have not been gung-ho to
switch.  Maybe now that it's more mature, I should give it another
shot.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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] New: opencv-2.4.11-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* libopencv2.4-2.4.11-1
* libopencv-devel-2.4.11-1
* python-cv-2.4.11-1

OpenCV (Open Source Computer Vision) is a library of programming
functions for real time computer vision. Example applications of the
OpenCV library are Human-Computer Interaction; Object Identification,
Segmentation and Recognition; Face Recognition; Gesture Recognition;
Camera and Motion Tracking, Ego Motion, Motion Understanding; Structure
>From Motion; Stereo and Multi-Camera Calibration and Depth Computation;
Mobile Robotics.

--
Yaakov

--
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] New: spice-0.12.6-1, xf86-video-qxl-0.1.4-1 (64-bit only)

[Yaakov Selkowitz]

The following packages have been added to the 64-bit distribution only:

* libspice-server1-0.12.6-1
* libspice-server-devel-0.12.6-1
* xf86-video-qxl-0.1.4-1

The Spice project aims to provide a complete open source solution
for interaction with virtualized desktop devices.  These packages
provide a Spice driver for the Xorg server, along with the Xspice script
for customising the launching of the server with this driver.  Due to
limitations of the Spice protocol, these packages are only available for
the 64-bit distribution.

--
Yaakov

--
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: pthread_kill: signals remain pending after target thread exits

[John Carey]

> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Monday, November 02, 2015 9:58 AM
> On Nov  2 15:18, Corinna Vinschen wrote:
> > On Oct 29 16:16, John Carey wrote:
> > > > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > > > Sent: Thursday, October 29, 2015 1:02 AM
> > > > On Oct 28 10:14, Corinna Vinschen wrote:
> > > ...
> > > > > > Thanks; that was fast!  I tried replacing cygwin1.dll with 
> > > > > > cygwin1-20151023.dll .
> > > > > >
> > > > > > The original test case now works.  I checked some of my other tests,
> > > > > > and unfortunately some of them failed, so I extracted out a new test
> > > > > > case, which is attached.  My guess is that something is subtly 
> > > > > > different
> > > > > > about the timing on this test.
> > > > >
> > > > > Is this a regression?  Did it work with 2.2.1?
> > > >
> > > > Answering myself here, this didn't work at all in 2.2.1.  I can
> > > > reproduce the problem and I'm going to take a look.  Not sure if
> > > > there's a quick solution, though.  This looks like a deadlock
> > > > situation.  The signal definitely got send, I just don't see yet
> > > > why it's not handled in wait_sig.
> > >
> > > Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
> > > differ: there is no Cygwin process left hanging that cannot be
> > > killed by a Cygwin signal.
> > >
> > > But both tests appear to pass in Cygwin 1.7.9, so in that sense
> > > it is a regression, just not a recent one.
> >
> > The regression here was my original fix.  It didn't clear pending
> > signals for an exiting thread thorougly enough.  I applied a patch now
> > which should fix this issue.  I'll upload a new developer snapshot to
> > https://cygwin.com/snapshots/ later today or tomorrow (still looking
> > into the PrlFS issue).  Please give it a try.
> 
> Snapshot is up.  The fix is in the 2.3.0-0.5 test release as well.
> Please give any one of them a try.

I tested snapshot cygwin1-20151102.dll, and it works in all of my tests.  Nice!

I'm glad you figured out how to delete those pending signals.

Thanks,
John Carey

--
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: Pop up GUI remotely via SSH

[Linda Walsh]

trimat wrote:

Hi all,
I would like to pup up on Windows 7 the GUI of a program started remotely
from SSH. I can't obtain this with *cygstart* even though I see the process
running in Windows Task Manager. Trying to add /--interactive/ flag to
Cygwin service /sshd/, the service doesn't start.


	Am unclear here.  


Where are you starting ssh from and where is sshd running?

Are you trying - say, when you login to windows, 1st have it
run the Xserver, then have a 2nd program run ssh to a remote (linux? 
Windows?) machine, where it starts an X-GUI, on the remote (linux? cygwin

on windows?) that display back on the machine you just logged into?

Are you are you have the Xserver running locally before you run
the ssh command?

--
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: Using cp converts windows junctions to a cywin symlink; a security-config override

[Andrey Repin]

Greetings, Linda Walsh!

>> > I was copying a directory of files, some of which were windows junctions.
>> > These got converted to a cygwin symlink.  Although I am impressed that 
>> > there
>> > are such a thing for those OSs/drives that do not support such things, for 
>> > those
>> > that do, I think it would be good to keep the copy a junction.  Otherwise,
>> > things can get messy.

>> > Can this be corrected?
> ---

> (BTW -- you do know about the 'winsymlinks:native' setting in the
> CYGWIN environment variable?  It might be of some use.)

> Andrey wrote:
>> Unfortunately, even on systems, that do support symlinks functionality,
>> it is restricted by UAC and not easily unlocked.
> --- 
> Actually that's control by Windows group policy.

Yes, I know. But when UAC is enabled, it overriding this policy setting.
That's why I said that you need either admin console, or UAC turned off.

> It's alot like whether not 'users' can control 'mounts' on linux.
> It can be allowed, but doing so categorically might not be considered
> wise.

Microsoft does not follow common logic.

>> You'd need an admin shell or a user profile with UAC turned off and
>> permissions correctly configured to exploit native symlinks.
> --- 
> Or the system administrator would have to enable user-control of local
> symlinks.

...

> On my windows machine, unprivileged users are able to create all 4 types
> of symbolic links.

Do you have UAC enabled?

>> And Cygwin does not support creation of directory junctions to the best
>> of my knowledge. :(
> ---
> Neither does linux support creation of user-controlled mounts.

However, Windows allows creation of directory junctions just fine.
But blocks Symlinks.


-- 
With best regards,
Andrey Repin
Tuesday, November 3, 2015 02:34:22

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mounting a network share

[Linda Walsh]

Andrey Repin wrote:

Greetings, Mike Brown!


I'm remotely loggin in to my P box and would lke to mount one of the NAS
Samba shares.  M$ likes to unmount the share after a period of time,
but because it was mounted, the pasword is needed (I hope).



When I try the following:



mount \\192.168.1.40\Public /cygdrive/p

---
Got to watch out for the those backslashes:

This seems to work:


mount //ishtar/tmp /tmp/tmnt

mount: defaulting to 'notexec' mount option for speed since native path
  references a remote share.  Use '-f' option to override.
/tmp> df /tmp/tmnt
Filesystem  Size  Used Avail Use% Mounted on
//ishtar/tmp   12G  8.4G  3.7G  70% /tmp/tmnt

Though I'd likely use 'net use' as others mentioned.



--
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: Using cp converts windows junctions to a cywin symlink; a security-config override

[Linda Walsh]

Andrey Repin wrote:
Greetings, Adrian H!


> I was copying a directory of files, some of which were windows junctions.
> These got converted to a cygwin symlink.  Although I am impressed that there
> are such a thing for those OSs/drives that do not support such things, for 
those
> that do, I think it would be good to keep the copy a junction.  Otherwise,
> things can get messy.



> Can this be corrected?

---

(BTW -- you do know about the 'winsymlinks:native' setting in the
CYGWIN environment variable?  It might be of some use.)

Andrey wrote:

Unfortunately, even on systems, that do support symlinks functionality,
it is restricted by UAC and not easily unlocked.
--- 
Actually that's control by Windows group policy.


It's alot like whether not 'users' can control 'mounts' on linux.
It can be allowed, but doing so categorically might not be considered
wise.


You'd need an admin shell or a user profile with UAC turned off and
permissions correctly configured to exploit native symlinks.
--- 
Or the system administrator would have to enable user-control of local

symlinks.

The ability to allow users to create and use symlinks is control through
4 settings:


fsutil behavior query SymlinkEvaluation
* Local to local symbolic links are enabled.  
* Local to remote symbolic links are enabled.  
* Remote to local symbolic links are enabled.  
* Remote to remote symbolic links are enabled.


--- 


On my windows machine, unprivileged users are able to create all 4 types
of symbolic links.

As for junctions and mountvols -- they require the same privileges on
windows as they do on linux.

I.e. a normal user can't mount or graft portions of the file system other
places -- mount is normally restricted to root-only.  Having cygwin
destroy/overwrite linux-comparable 'mounts' would be and should be
considered a serious security bug.

If I mount a linux dir at another location -- imagine if 'cp' changed
those mount point to symbolic links (which no longer work consistently or
the same on linux as they use to, as some security-spazes came up with the
idea that being able to create a symlink (not hardlink) to a file you
don't own, was considered a security risk -- even though in reality
symlinks are safer than hardlinks in such cases, because the symlinks have
to traverse the intervening directories and security checks.  On windows,
the "allow traversing paths you don't have access to" is a privilege that
has been used to allow users access to area they didn't normally have
access to.  However, on linux there never was such a privilege, so the
added the ability to mount normally "private" areas in other places --
going around the intermediate path-walk-security checks.  


Now with the mount option, the default on most distros is to disable
creating symlinks to files you don't own -- which doesn't serve the same
purpose -- since such symlinks STILL follow all the intervening security
checks at each directory.

Note--disabling the windows privilege to bypass traversed directory
security checks would achieve the same effect on windows as it does on
linux, but MS strongly advises against doing this, as so much software
makes use of this feature and assumes it is in place (it is the default).

To find out more about the linux google on
/proc/sys/fs/protected_hardlinks & /proc/sys/fs/protected_symlinks


And Cygwin does not support creation of directory junctions to the best
of my knowledge. :(

---
Neither does linux support creation of user-controlled mounts.


Not have cygwin destroy "volume mount points" that are
a parallel to linux's ability to mount any directory anywhere else, would
be very useful. Destroying the mountpoints as it does now, is
a hacker's dream, as they can destroy a local admin's mounting
of a read-only dir there and allow potentially virus laden programs
to replace them.

Nice.




--
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: TP_NUM_C_BUFS too small

[Helmut Karlowski]

Am 02.11.2015, 12:15 Uhr, schrieb Corinna Vinschen:

Glad it's fixed!  For the record, could you say what sort of bug would  
cause

a fatal internal error like that?
Just curious,


Me too.  Sounds like some kind of recursion.


It all happened after I had replaced all strcpy/strcat by strlcpy like  
this:


strcpy(t,s) -> pos = strlcpy(t,s,size)
strcat(t,s) -> pos += strlcpy(t+pos,s,size-pos)

At some point the pos-parameter was wrong and the resulting string became  
something undesired. And that string probably was passed to fopen, maybe  
pos became very large way beyond the boundaries of the string which is  
from the stack.


It's hard to reproduce what happened in a simple case, and I was in some  
hurry then, but I saved the strace-output:


  459 4265672 [main] ue 460 open: open(u, 0x0)
   33 4265705 [main] ue 460 normalize_posix_path: src u
   33 4265738 [main] ue 460 cwdstuff::get: posix /usr/src/ue314/bin
   32 4265770 [main] ue 460 cwdstuff::get: (/usr/src/ue314/bin) =  
cwdstuff::get (0x8008, 32768, 1, 0), errno 2
   33 4265803 [main] ue 460 normalize_posix_path: /usr/src/ue314/bin/u =  
normalize_posix_path (u)
   33 4265836 [main] ue 460 mount_info::conv_to_win32_path:  
conv_to_win32_path (/usr/src/ue314/bin/u)

   33 4265869 [main] ue 460 set_flags: flags: binary (0x2)
   33 4265902 [main] ue 460 mount_info::conv_to_win32_path: src_path  
/usr/src/ue314/bin/u, dst C:\cygwin\usr\src\ue314\bin\u, flags 0x3000A, rc  
0
   63 4265965 [main] ue 460 symlink_info::check: 0x0 = NtCreateFile  
(\??\C:\cygwin\usr\src\ue314\bin\u)

   49 4266014 [main] ue 460 symlink_info::check: not a symlink
   47 4266061 [main] ue 460 symlink_info::check: 0 =  
symlink.check(C:\cygwin\usr\src\ue314\bin\u, 0x29B598) (0x3000A)
   35 4266096 [main] ue 460 path_conv::check:  
this->path(C:\cygwin\usr\src\ue314\bin\u), has_acls(1)

   37 4266133 [main] ue 460 build_fh_pc: fh 0x61302754, dev 00C3
   34 4266167 [main] ue 460 fhandler_base::open:  
(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
   70 4266237 [main] ue 460 fhandler_base::set_flags: flags 0x108000,  
supplied_bin 0x1
   34 4266271 [main] ue 460 fhandler_base::set_flags: filemode set to  
binary
   33 4266304 [main] ue 460 fhandler_base::open: 0x0 = NtCreateFile  
(0x170, 0x8010, \??\C:\cygwin\usr\src\ue314\bin\u, io, NULL, 0x0, 0x7,  
0x1, 0x4020, NULL, 0)
   35 4266339 [main] ue 460 fhandler_base::open: 1 =  
fhandler_base::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
   41 4266380 [main] ue 460 fhandler_base::open_fs: 1 =  
fhandler_disk_file::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x8000)

   34 4266414 [main] ue 460 open: 3 = open(u, 0x8000)
  186 4266600 [main] ue 460 _cygwin_istext_for_stdio: fd 3: opened as  
binary

  232 4266832 [main] ue 460 close: close(3)
   32 4266864 [main] ue 460 fhandler_base::close: closing  
'/usr/src/ue314/bin/u' handle 0x170

   49 4266913 [main] ue 460 close: 0 = close(3)
  460 4267373 [main] 20 460 open: open(u, 0x0)

This loops some 100 times, then:

  460 4267373 [main] 20 460 open: open(u, 0x0)
   32 4267405 [main] 20 460 normalize_posix_path: src u
   32 4267437 [main] 20 460 cwdstuff::get: posix /usr/src/ue314/bin
   33 4267470 [main] 20 460 cwdstuff::get: (/usr/src/ue314/bin) =  
cwdstuff::get (0x8008, 32768, 1, 0), errno 2
   33 4267503 [main] 20 460 normalize_posix_path: /usr/src/ue314/bin/u =  
normalize_posix_path (u)
   32 4267535 [main] 20 460 mount_info::conv_to_win32_path:  
conv_to_win32_path (/usr/src/ue314/bin/u)

   34 4267569 [main] 20 460 set_flags: flags: binary (0x2)
   32 4267601 [main] 20 460 mount_info::conv_to_win32_path: src_path  
/usr/src/ue314/bin/u, dst C:\cygwin\usr\src\ue314\bin\u, flags 0x3000A, rc  
0
   59 4267660 [main] 20 460 symlink_info::check: 0x0 = NtCreateFile  
(\??\C:\cygwin\usr\src\ue314\bin\u)

   50 4267710 [main] 20 460 symlink_info::check: not a symlink
   47 4267757 [main] 20 460 symlink_info::check: 0 =  
symlink.check(C:\cygwin\usr\src\ue314\bin\u, 0x29B598) (0x3000A)
   35 4267792 [main] 20 460 path_conv::check:  
this->path(C:\cygwin\usr\src\ue314\bin\u), has_acls(1)

   36 4267828 [main] 20 460 build_fh_pc: fh 0x61302754, dev 00C3
   33 4267861 [main] 20 460 fhandler_base::open:  
(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
   72 4267933 [main] 20 460 fhandler_base::set_flags: flags 0x108000,  
supplied_bin 0x1
   34 4267967 [main] 20 460 fhandler_base::set_flags: filemode set to  
binary
   33 4268000 [main] 20 460 fhandler_base::open: 0x0 = NtCreateFile  
(0x16C, 0x8010, \??\C:\cygwin\usr\src\ue314\bin\u, io, NULL, 0x0, 0x7,  
0x1, 0x4020, NULL, 0)
   34 4268034 [main] 20 460 fhandler_base::open: 1 =  
fhandler_base::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
   42 4268076 [main] 20 460 fhandler_base::open_fs: 1 =  
fhandler_disk_file::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x8000)

   34 4268110 [main] 20 460 open: 3 = open(u, 0x8000)
  186 4268296 [main] 20 460 _cygwin_istext_for_stdio: fd 3: opened as  
binary

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

[Jonathan Lennox]

On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
saying:

> On Nov  2 08:08, Jonathan Lennox wrote:
> > On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
> > saying:
> > 
> > > On Nov  2 04:38, Jonathan Lennox wrote:
> > > > Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac 
> > > > drives
> > > > (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is.  
> > > > So I
> > > > can't test hard links as administrator.
> > > 
> > > That's a security feature of UAC.  You can change that in the registry.
> > > As administrator:
> > > 
> > >   regtool -d set 
> > > /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections
> > >  1
> > > 
> > > Then reboot.
> > 
> > Didn't work:
> > 
> > $ ls /cygdrive/
> > c  d  e
> > 
> > $ regtool get 
> > /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections
> > 
>  ^^^?
> 
> That should print "1"
> 
> EnableLinkedConnections is a DWORD value and should be set to 1.

Yes, sorry, it does print 1. Copy & Paste error.

Given "cyg Simple"'s comment, I guess I need to recreate the mapped drives as
the Administrator user?

> > > I added support for this filesystem (called prlfs in mount output) and
> > > without hardlink support for now.  I uploaded a new developer snapshot
> > > to https://cygwin.com/snapshots/ Please give it a try.
> > 
> > No, still seeing the failure in the snapshot:
> > 
> > $ ./stat-size-test.exe /cygdrive/y/foo ~/foo
> > /cygdrive/y/foo: fstat: st_size=0
> > /cygdrive/y/foo: stat: st_size=12
> > /home/jonathan/foo: fstat: st_size=12
> > /home/jonathan/foo: stat: st_size=12
> 
> Weird.  There should be no FileNetworkOpenInformation call anymore for
> Netapp and the PrlSF filesystem.
> 
> Does Cygwin correctly recognize the FS?  What does `mount' print?  It
> should print `type prlfs'.

$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
E: on /cygdrive/e type iso9660 (binary,posix=0,user,noumount,auto)
U: on /cygdrive/u type prlsf (binary,posix=0,user,noumount,auto)
V: on /cygdrive/v type prlsf (binary,posix=0,user,noumount,auto)
W: on /cygdrive/w type prlsf (binary,posix=0,user,noumount,auto)
X: on /cygdrive/x type prlsf (binary,posix=0,user,noumount,auto)
Y: on /cygdrive/y type prlsf (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type prlsf (binary,posix=0,user,noumount,auto)


> Can you please once again call `/usr/lib/csih/getVolInfo.exe Z:' and
> `/usr/lib/csih/getVolInfo.exe Y:' and paste the output here?  I'm not
> quite sure because the original getVolInfo call returned a filesystem
> type of "PrlSF", not "PrlFS" as I had expected.  Cygwin now checks for
> "PrlSF".
> 

$ /usr/lib/csih/getVolInfo.exe /cygdrive/z
Device Type: 7
Characteristics: 10
Volume Name: 
Serial Number  : 0
Max Filenamelength : 255
Filesystemname : 
Flags  : 3
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: FALSE
  FILE_PERSISTENT_ACLS: FALSE
  FILE_FILE_COMPRESSION   : FALSE
  FILE_VOLUME_QUOTAS  : FALSE
  FILE_SUPPORTS_SPARSE_FILES  : FALSE
  FILE_SUPPORTS_REPARSE_POINTS: FALSE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: FALSE
  FILE_SUPPORTS_ENCRYPTION: FALSE
  FILE_NAMED_STREAMS  : FALSE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE

$ /usr/lib/csih/getVolInfo.exe /cygdrive/y
Device Type: 7
Characteristics: 10
Volume Name: 
Serial Number  : 0
Max Filenamelength : 255
Filesystemname : 
Flags  : 3
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: FALSE
  FILE_PERSISTENT_ACLS: FALSE
  FILE_FILE_COMPRESSION   : FALSE
  FILE_VOLUME_QUOTAS  : FALSE
  FILE_SUPPORTS_SPARSE_FILES  : FALSE
  FILE_SUPPORTS_REPARSE_POINTS: FALSE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: FALSE
  FILE_SUPPORTS_ENCRYPTION: FALSE
  FILE_NAMED_STREAMS  : FALSE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE

(Note that the literal "/usr/lib/csih/getVolInfo.exe Z:" printed
"NtOpenFile(\??\C:\cygwin64\home\jonathan\Z:) failed, c033", so I assume
that's not what you want.)

-- 
Jonathan Lennox
len...@cs.columbia.edu

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:   

Re: xterm 320-1 won't start with XTerm*faceName set in .Xresources

[Yaakov Selkowitz]

On Mon, 2015-11-02 at 15:52 -0500, Brian Neu wrote:
> Ran setup64.exe to update cygwin today, and then the xterm window 
> wouldn't come up.  I was able to troubleshoot it down to the 
> XTerm*faceName in my ~/.Xresources
> 
> Commented out, it works, but I much prefer the other font.  Any ideas?

Perhaps you are missing your preferred font.  What had you specified for
XTerm*faceName?

--
Yaakov



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

xterm 320-1 won't start with XTerm*faceName set in .Xresources

[Brian Neu]

Ran setup64.exe to update cygwin today, and then the xterm window 
wouldn't come up.  I was able to troubleshoot it down to the 
XTerm*faceName in my ~/.Xresources


Commented out, it works, but I much prefer the other font.  Any ideas?



2015/11/02 12:55:45 Extracting  
_update-info-dir/_update-info-dir-00488-1.tar.bz2
2015/11/02 12:55:45 Extracting  base-files/base-files-4.2-4.tar.xz
2015/11/02 12:55:45 Extracting  bash/bash-4.3.42-4.tar.xz
2015/11/02 12:55:47 Extracting  ca-certificates/ca-certificates-2.5-1.tar.xz
2015/11/02 12:55:47 Extracting  coreutils/coreutils-8.24-3.tar.xz
2015/11/02 12:55:51 Extracting  csih/csih-0.9.9-1.tar.xz
2015/11/02 12:55:51 Extracting  cygwin/cygwin-2.2.1-1.tar.xz
2015/11/02 12:55:54 Extracting  
cygwin/cygwin-devel/cygwin-devel-2.2.1-1.tar.xz
2015/11/02 12:55:56 Extracting  dos2unix/dos2unix-7.3.1-1.tar.xz
2015/11/02 12:55:57 Extracting  mesa/dri-drivers/dri-drivers-11.0.4-1.tar.xz
2015/11/02 12:55:57 Extracting  file/file-5.24-1.tar.xz
2015/11/02 12:55:58 Extracting  fontconfig/fontconfig-2.11.1-3.tar.xz
2015/11/02 12:55:58 Extracting  
gtk2.0/gtk2.0-engines-pixmap/gtk2.0-engines-pixmap-2.24.28-2.tar.xz
2015/11/02 12:55:58 Extracting  less/less-481-1.tar.xz
2015/11/02 12:55:58 Extracting  mesa/libEGL1/libEGL1-11.0.4-1.tar.xz
2015/11/02 12:55:58 Extracting  mesa/libGL1/libGL1-11.0.4-1.tar.xz
2015/11/02 12:55:58 Extracting  cairo/libcairo2/libcairo2-1.14.2-1.tar.xz
2015/11/02 12:55:59 Extracting  
fontconfig/libfontconfig1/libfontconfig1-2.11.1-3.tar.xz
2015/11/02 12:55:59 Extracting  
freetype2/libfreetype6/libfreetype6-2.5.5-2.tar.xz
2015/11/02 12:56:00 Extracting  
gdk-pixbuf2.0/libgdk_pixbuf2.0_0/libgdk_pixbuf2.0_0-2.31.7-1.tar.xz
2015/11/02 12:56:02 Extracting  mesa/libglapi0/libglapi0-11.0.4-1.tar.xz
2015/11/02 12:56:02 Extracting  
gnutls/libgnutls28/libgnutls28-3.3.17-1.tar.xz
2015/11/02 12:56:02 Extracting  
krb5/libgssapi_krb5_2/libgssapi_krb5_2-1.13.2-2.tar.xz
2015/11/02 12:56:02 Extracting  
gtk2.0/libgtk2.0_0/libgtk2.0_0-2.24.28-2.tar.xz
2015/11/02 12:56:04 Extracting  
harfbuzz/libharfbuzz0/libharfbuzz0-1.0.5-1.tar.xz
2015/11/02 12:56:04 Extracting  gettext/libintl8/libintl8-0.19.5.1-2.tar.xz
2015/11/02 12:56:04 Extracting  
libjpeg-turbo/libjpeg8/libjpeg8-1.4.2-1.tar.xz
2015/11/02 12:56:04 Extracting  
krb5/libk5crypto3/libk5crypto3-1.13.2-2.tar.xz
2015/11/02 12:56:04 Extracting  krb5/libkrb5_3/libkrb5_3-1.13.2-2.tar.xz
2015/11/02 12:56:04 Extracting  
krb5/libkrb5support0/libkrb5support0-1.13.2-2.tar.xz
2015/11/02 12:56:04 Extracting  
mysql/libmysqlclient18/libmysqlclient18-5.5.45-1.tar.xz
2015/11/02 12:56:05 Extracting  
ncurses/libncursesw10/libncursesw10-6.0-1.20151017.tar.xz
2015/11/02 12:56:05 Extracting  pcre/libpcre1/libpcre1-8.37-2.tar.xz
2015/11/02 12:56:05 Extracting  
pixman/libpixman1_0/libpixman1_0-0.32.8-1.tar.xz
2015/11/02 12:56:05 Extracting  libpng/libpng16/libpng16-1.6.18-1.tar.xz
2015/11/02 12:56:05 Extracting  
sqlite3/libsqlite3_0/libsqlite3_0-3.9.0-1.tar.xz
2015/11/02 12:56:05 Extracting  libtasn1/libtasn1_6/libtasn1_6-4.5-1.tar.xz
2015/11/02 12:56:05 Extracting  tiff/libtiff6/libtiff6-4.0.6-1.tar.xz
2015/11/02 12:56:05 Extracting  libvpx/libvpx1/libvpx1-1.3.0-2.tar.xz
2015/11/02 12:56:06 Extracting  vte/libvte9/libvte9-0.28.2-6.tar.xz
2015/11/02 12:56:06 Extracting  
libxcb/libxcb-glx0/libxcb-glx0-1.11.1-1.tar.xz
2015/11/02 12:56:06 Extracting  
libxcb/libxcb-render0/libxcb-render0-1.11.1-1.tar.xz
2015/11/02 12:56:07 Extracting  
libxcb/libxcb-shm0/libxcb-shm0-1.11.1-1.tar.xz
2015/11/02 12:56:07 Extracting  libxcb/libxcb1/libxcb1-1.11.1-1.tar.xz
2015/11/02 12:56:07 Extracting  man-db/man-db-2.7.4-1.tar.xz
2015/11/02 12:56:08 Extracting  mintty/mintty-2.1.5-0.tar.xz
2015/11/02 12:56:09 Extracting  mysql/mysql-5.5.45-1.tar.xz
2015/11/02 12:56:11 Extracting  openssh/openssh-7.1p1-1.tar.xz
2015/11/02 12:56:12 Extracting  perl-CGI/perl-CGI-4.21-1.tar.xz
2015/11/02 12:56:12 Extracting  
perl-HTML-Parser/perl-HTML-Parser-3.71-3.tar.xz
2015/11/02 12:56:12 Extracting  
perl-HTML-Tagset/perl-HTML-Tagset-3.20-5.tar.xz
2015/11/02 12:56:13 Extracting  
perl-Pod-Simple/perl-Pod-Simple-3.31-1.tar.xz
2015/11/02 12:56:13 Extracting  php/php-5.6.14-2.tar.xz
2015/11/02 12:56:14 Extracting  php/php-gd/php-gd-5.6.14-2.tar.xz
2015/11/02 12:56:14 Extracting  php/php-mssql/php-mssql-5.6.14-2.tar.xz
2015/11/02 12:56:14 Extracting  
php/php-pdo_mysql/php-pdo_mysql-5.6.14-2.tar.xz
2015/11/02 12:56:15 Extracting  pwget/pwget-2015.0927+git36776ae-1.tar.xz
2015/11/02 12:56:15 Extracting  run/run-1.3.4-2.tar.xz
2015/11/02 12:56:15 Extracting  screen/screen-4.3.1-2.tar.xz
2015/11/02 12:56:16 Extracting  
ncurses/terminfo/terminfo-6.0-1.20151017.tar.xz
2015/11/02 12:56:21 Extracting  tmux/tmux-2.1-1.tar.xz
2015/11/02 12:56

Re: Using cp converts windows junctions to a cywin symlink

[Andrey Repin]

Greetings, Adrian H!

> I was copying a directory of files, some of which were windows junctions.
> These got converted to a cygwin symlink.  Although I am impressed that there
> are such a thing for those OSs/drives that do not support such things, for 
> those
> that do, I think it would be good to keep the copy a junction.  Otherwise,
> things can get messy.

> Can this be corrected?

Unfortunately, even on systems, that do support symlinks functionality, it is
restricted by UAC and not easily unlocked.
You'd need an admin shell or a user profile with UAC turned off and permissions
correctly configured to exploit native symlinks.
And Cygwin does not support creation of directory junctions to the best of my
knowledge. :(


-- 
With best regards,
Andrey Repin
Monday, November 2, 2015 22:48:43

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mounting a network share

[Andrey Repin]

Greetings, Mike Brown!

>> > > If you want to do it from Cygwin side, use fstab and don't use /cygdrive
>> > > prefix. It is for automatic mounts ONLY.
>> > 
>> > I went and found the Cygwin web page that describes fstab.  What it doesn't
>> > say is how to use it.
>> 
>> It does: https://cygwin.com/cygwin-ug-net/using.html#mount-table

> What I mean is that I was able to create an entry, but I have no idea how to
> get the mount program to read the contents.

Cygwin's fstab only accepts 'bind mounts' (in *NIX terms). The article Corinna
mentioned clearly explains that.
Another difference from *NIX is that it is read and interpreted by Cygwin core
(cygwin1.dll) when a new process tree starts.

>> > I have the following entry:
>> > 
>> > 192.168.1.40:/Public /Public nfs noacl 0 0
>>   
>> 
>> This syntax isn't known in Windows.  Use the same syntax as with SMB
>> shares, just use forward slashes:
>> 
>>   //192.168.1.40/Public /Public foo binary 0 0
>> 
>> "noacl" has no meaning on NFS shares, btw. 

> No there no explantion on how to enter a user and password.

Because there's no such place. The resource must be available to the user.

Before we continue this discussion, I suggest to re-read the two paragraphs on
the cygwin.com main page. What Cygwin is and it is not.

You expect kernel OS functionality from a userland application. That's not how
Cygwin works. Cygwin leverages the operating system functionality to create a
level field for porting applications to Windows.

And to your 'net use' issues, 'net help use' should have been your first stop.
Yes, you can just call 'net use ' without specifying the name to
simply authenticate yourself with the resource.
Mind you, specifying a password in command line is always a bad idea. You
never know, where that password would be stored or displayed in between
terminal and the called application.


-- 
With best regards,
Andrey Repin
Monday, November 2, 2015 22:33:09

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unison 2.43.3 fails to synchronize execute permission bit

[Ms. Alex Hankins]

There was a bug with the umask in the test script.  I have fixed it
and attached it.

On Thu, Oct 29, 2015 at 11:26 AM, L <***> wrote:
> On Wed, Oct 28, 2015 at 2:55 PM,   wrote:
>> When synchronizing two directories on the same NTFS-formatted drive, unison 
>> (with -perms 0o1777) fails to set execute permissions on new files.  (It 
>> also fails to detect changes in execute permissions and to set them on 
>> existing files.)
>>...
>
> I forgot cygcheck.out.  I have attached it.
>
> Ms. Alex Hankins


test-whether-unison-preserves-execute-permissions.bash
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

Using cp converts windows junctions to a cywin symlink

[Adrian H]

I was copying a directory of files, some of which were windows junctions.
These got converted to a cygwin symlink.  Although I am impressed that there
are such a thing for those OSs/drives that do not support such things, for those
that do, I think it would be good to keep the copy a junction.  Otherwise,
things can get messy.

Can this be corrected?

Thanks,


A

--
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: Mounting a network share

[Mike Brown]

On Mon, Nov 02, 2015 at 05:26:51PM +0100, Corinna Vinschen wrote:
> On Nov  2 10:03, Mike Brown wrote:
> > On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
> > > If you want to do it from Cygwin side, use fstab and don't use /cygdrive
> > > prefix. It is for automatic mounts ONLY.
> > 
> > I went and found the Cygwin web page that describes fstab.  What it doesn't
> > say is how to use it.
> 
> It does: https://cygwin.com/cygwin-ug-net/using.html#mount-table

What I mean is that I was able to create an entry, but I have no idea how to
get the mount program to read the contents.

> > I have the following entry:
> > 
> > 192.168.1.40:/Public /Public nfs noacl 0 0
>   
> 
> This syntax isn't known in Windows.  Use the same syntax as with SMB
> shares, just use forward slashes:
> 
>   //192.168.1.40/Public /Public foo binary 0 0
> 
> "noacl" has no meaning on NFS shares, btw. 

No there no explantion on how to enter a user and password.  I tried the nfs
syntax because it doesn't require a password.

MB
-- 
e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII
6082066...@email.uscc.net (140 char limit)   \ / Ribbon Campaign
Visit - URL: http://vidiot.com/   X  Against
 http://vidiot.net/  / \ HTML Email
"What do you say Beckett. Wanna have a baby?" - Castle to Det. Beckett
"How long have I been gone?" Alexis after seeing Castle and Beckett w/ baby
 - Castle - 11/25/13

--
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: pthread_kill: signals remain pending after target thread exits

[Corinna Vinschen]

On Nov  2 15:18, Corinna Vinschen wrote:
> On Oct 29 16:16, John Carey wrote:
> > > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > > Sent: Thursday, October 29, 2015 1:02 AM
> > > On Oct 28 10:14, Corinna Vinschen wrote:
> > ...
> > > > > Thanks; that was fast!  I tried replacing cygwin1.dll with 
> > > > > cygwin1-20151023.dll .
> > > > >
> > > > > The original test case now works.  I checked some of my other tests,
> > > > > and unfortunately some of them failed, so I extracted out a new test
> > > > > case, which is attached.  My guess is that something is subtly 
> > > > > different
> > > > > about the timing on this test.
> > > >
> > > > Is this a regression?  Did it work with 2.2.1?
> > > 
> > > Answering myself here, this didn't work at all in 2.2.1.  I can
> > > reproduce the problem and I'm going to take a look.  Not sure if
> > > there's a quick solution, though.  This looks like a deadlock
> > > situation.  The signal definitely got send, I just don't see yet
> > > why it's not handled in wait_sig.
> > 
> > Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
> > differ: there is no Cygwin process left hanging that cannot be
> > killed by a Cygwin signal.
> > 
> > But both tests appear to pass in Cygwin 1.7.9, so in that sense
> > it is a regression, just not a recent one.
> 
> The regression here was my original fix.  It didn't clear pending
> signals for an exiting thread thorougly enough.  I applied a patch now
> which should fix this issue.  I'll upload a new developer snapshot to
> https://cygwin.com/snapshots/ later today or tomorrow (still looking
> into the PrlFS issue).  Please give it a try.

Snapshot is up.  The fix is in the 2.3.0-0.5 test release as well.
Please give any one of them a try.


Thanks,
Corinna

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


pgpSoNV2xJUHR.pgp
Description: PGP signature

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.5

[Corinna Vinschen]

Hi Cygwin friends and users,


I released a new TEST version of Cygwin, 2.3.0-0.5.

This test release adds all Cygwin-related patches applied after the 
2.3.0-0.4 test release.  The support for the Parallels Desktop FS
is apparently not working yet, but that might get fixed in the next
test release.

Other than that, the original intention, testing the "new POSIX ACL
handling reloaded" code, still applies.

This is the "new POSIX ACL handling reloaded" release.

In local testing I successfully integrated AuthZ into the current Cygwin
code to generate more correct user permissions by being able to generate
effective permissions for arbitrary users.

This success convinced me that it might be possible to pick up the POSIX
permission rewrite originally targeted for the 2.0.0 release and try to
update it using AuthZ and generally revamp it to reflect effective
permissions better.

My local testing looks good, but this is a major change, so this code
really needs a lot more testing in various scenarios.  Especially
some Windows ACLs created in corporate environments are often a hard
nut to crack, and the example from

https://cygwin.com/ml/cygwin/2015-04/msg00513.html

which was the ultimate downfall of the original implementation is
the stuff which needs some good testing.

There's, as usual, a downside: AuthZ leans a bit to the slow side.
Cygwin caches information already gathered once on a per-process basis,
but in locally crafted worst case scenarios (`ls' on lots of file owned
by lots of different users and groups) the slowdown may be up to 25%.
But that's really just a worst case, in the usual scenarios the slowdown
should be mostly unnoticable.

To alleviate the problem, the AuthZ code is fortunately only called for
non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
pure Cygwin environment (e.g., some build directory only used with
Cygwin tools) AuthZ should be practically unused.

Apart from the aforementioned code changes to "just do it right", there
are two additional changes I implemented for this new POSIX ACL revamp
release:

- I reverted the questionable change I added to 2.0.0-0.7 in terms of
  chmod group permission handling.  The original description of this
  change was:

If you have a non-trivial ACL with secondary accounts and thus a
mask value, chmod is supposed to change only the mask, not the
permissions of the primary group.  However, if the primary group has
few permissions to begin with, the result is really surprising.  ls
-l would, e.g., show read/write perms for the group, but the group
might still have only read perms.

Personally I find this chmod behaviour really, really bad, so I took
the liberty to change it in a way which gives a much less surprising
result:  If you call chmod on a non-trivial ACL, the group
permissions will be used for the primary group and the mask.

- setfacl(1) now accepts the combination of the -b and -k options, just as
  on Linux (here's looking at you Achim ;)).

As for the description what this implementation strives for, please see
http://linux.die.net/man/5/acl

All changes in this release so far:



What's new:
---

- strftime(3) supports %s (seconds since Epoch) now.

- posix_madvise(POSIX_MADV_WILLNEED) now utilizes OS functionality available
  starting with Windows 8/Server 2012.  Still a no-op on older systems.

- posix_madvise(POSIX_MADV_DONTNEED) now utilizes OS functionality available
  starting with Windows 8.1/Server 2012R2.  Still a no-op on older systems.

- sysconf() now supports returning CPU cache information:
  _SC_LEVEL1_ICACHE_SIZE, _SC_LEVEL1_ICACHE_ASSOC, _SC_LEVEL1_ICACHE_LINESIZE,
  _SC_LEVEL1_DCACHE_SIZE, _SC_LEVEL1_DCACHE_ASSOC, _SC_LEVEL1_DCACHE_LINESIZE,
  _SC_LEVEL2_CACHE_SIZE, _SC_LEVEL2_CACHE_ASSOC, _SC_LEVEL2_CACHE_LINESIZE,
  _SC_LEVEL3_CACHE_SIZE, _SC_LEVEL3_CACHE_ASSOC, _SC_LEVEL3_CACHE_LINESIZE,
  _SC_LEVEL4_CACHE_SIZE, _SC_LEVEL4_CACHE_ASSOC, _SC_LEVEL4_CACHE_LINESIZE

- New API: aligned_alloc, at_quick_exit, quick_exit.


What changed:
-

- setfacl(1) now allows to use the -b and -k option combined to allow reducing
  an ACL to only reflect standard POSIX permissions.

- Add support for Parallels Desktop FS (prlfs).


Bug Fixes
-

- Fix a hang when stracing a forking or spawning process without activating
  stracing of child processes.
  Addresses: https://cygwin.com/ml/cygwin/2015-08/msg00390.html

- Fix long-standing potential SEGV on 32 bit Cygwin when the dynamic loader
  for OS functions fails to load a function on Windows 7 or later.
  Addresses: No actual bug report known.

- sysconf _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN now handle more than
  64 CPUs on Windows 7 and later.

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

Re: Mounting a network share

[Roger Wells]

On 11/02/2015 11:18 AM, Corinna Vinschen wrote:
> On Nov  1 23:35, Mike Brown wrote:
>> On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
>>> net use //host/resource[/path] P: * /PERSISTENT /SAVECRED
>>
>> I got the following to be accepted:
>>
>> net use \\192.168.1.40\Public password /user:brown /persistant:yes
>>
>> The syntax doesn't have a place to where it should be mounted.
> 
> I missed that in my reply.  It has:
> 
>   net use X: \\server\share
> 
> when using this command in a Cygwin shell, keep in mind that backslashes
> need to be escaped in Unix shells:
> 
>   net use X: server\\share

or this works:
net use x: '\\server\share'
(single quotes)

> 
> 
> Corinna
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.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: Mounting a network share

[Corinna Vinschen]

On Nov  2 10:03, Mike Brown wrote:
> On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
> > If you want to do it from Cygwin side, use fstab and don't use /cygdrive
> > prefix. It is for automatic mounts ONLY.
> 
> I went and found the Cygwin web page that describes fstab.  What it doesn't
> say is how to use it.

It does: https://cygwin.com/cygwin-ug-net/using.html#mount-table

> I have the following entry:
> 
> 192.168.1.40:/Public /Public nfs noacl 0 0
  

This syntax isn't known in Windows.  Use the same syntax as with SMB
shares, just use forward slashes:

  //192.168.1.40/Public /Public foo binary 0 0

"noacl" has no meaning on NFS shares, btw. 


Corinna

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


pgplJvC6SG7i4.pgp
Description: PGP signature

Re: Mounting a network share

[Corinna Vinschen]

On Nov  1 23:35, Mike Brown wrote:
> On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
> > net use //host/resource[/path] P: * /PERSISTENT /SAVECRED
> 
> I got the following to be accepted:
> 
> net use \\192.168.1.40\Public password /user:brown /persistant:yes
> 
> The syntax doesn't have a place to where it should be mounted.

I missed that in my reply.  It has:

  net use X: \\server\share

when using this command in a Cygwin shell, keep in mind that backslashes
need to be escaped in Unix shells:

  net use X: server\\share


Corinna

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


pgpQZW5i4A7v4.pgp
Description: PGP signature

Re: Mounting a network share

[Mike Brown]

On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
> If you want to do it from Cygwin side, use fstab and don't use /cygdrive
> prefix. It is for automatic mounts ONLY.

I went and found the Cygwin web page that describes fstab.  What it doesn't
say is how to use it.  I have the following entry:

192.168.1.40:/Public /Public nfs noacl 0 0

But, when I enter "mount /Public" mount complains about not enough options and
shows me the help for command line usage.  It doesn't appear to look in the
fstab file for the entry.

I did create /Public, so that path is there.

I tried it via the command line and it bitched about /Public.

I have no idea what I am doing wrong.

MB
-- 
e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII
6082066...@email.uscc.net (140 char limit)   \ / Ribbon Campaign
Visit - URL: http://vidiot.com/   X  Against
 http://vidiot.net/  / \ HTML Email
"What do you say Beckett. Wanna have a baby?" - Castle to Det. Beckett
"How long have I been gone?" Alexis after seeing Castle and Beckett w/ baby
 - Castle - 11/25/13

--
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: compile ncurses "hello world" to run independent of cygwin?

[Corinna Vinschen]

On Nov  2 10:14, Greg Freemyer wrote:
> On Mon, Nov 2, 2015 at 7:48 AM, cyg Simple  wrote:
> > On 11/1/2015 11:09 PM, Darik Horn wrote:
> >>
> >> Unless there is a specific reason to cross through Cygwin, it could be
> >> easier to use the native MinGW environment directly:
> >>
> >> * http://www.mingw.org/wiki/Getting_Started
> >>
> >
> > Poppycock! There is no reason that the user couldn't use Cygwin as the
> > one and only system to build native binaries.
> 
> I'm relatively new to this mailing list.  Apologies if this is well
> covered ground
> 
> The last time I checked (a few years ago), my understanding was the
> cygwin dll's were licensed such that any programs using them had to be
> GPL (or equivalent).

Yes, when linking against the Cygwin DLL there are GPL issues.

But that wasn't what "cyg Simple" was referring to.  The Cygwin distro
comes with a Mingw-w64 cross compiler and libs.  When you use those to
create Mingw binaries, you are not linking against the Cygwin DLL.

So, as "cyg Simple" wrote, there's no reason that you can't use the
Cygwin distro as environment to build non-Cygwin binaries.

There's also the fact that the aforementioned mingw.org project is
rather behind.  The Mingw-w64 fork (which is used by Cygwin as well,
incidentally) is more up to speed in terms of WIndows lib and header
file support.


Corinna

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


pgpinEZzGRqRZ.pgp
Description: PGP signature

Re: compile ncurses "hello world" to run independent of cygwin?

[Darik Horn]

On Mon, Nov 2, 2015 at 10:14 AM, Greg Freemyer  wrote:
>
> The last time I checked (a few years ago), my understanding was the
> cygwin dll's were licensed such that any programs using them had to be
> GPL (or equivalent).
>
> Is that wrong?

No, that is still the case:

* https://cygwin.com/licensing.html


> If so, anyone wanting to write a commercial tool has to avoid the
> cygwin's core dll's.

Or buy a license.


> Does using mingw do so?

No, it is easier to avoid GPL obligations by using the MinGW runtime:

* http://www.mingw.org/license

--
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: compile ncurses "hello world" to run independent of cygwin?

[Greg Freemyer]

On Mon, Nov 2, 2015 at 7:48 AM, cyg Simple  wrote:
> On 11/1/2015 11:09 PM, Darik Horn wrote:
>>
>> Unless there is a specific reason to cross through Cygwin, it could be
>> easier to use the native MinGW environment directly:
>>
>> * http://www.mingw.org/wiki/Getting_Started
>>
>
> Poppycock! There is no reason that the user couldn't use Cygwin as the
> one and only system to build native binaries.

I'm relatively new to this mailing list.  Apologies if this is well
covered ground

The last time I checked (a few years ago), my understanding was the
cygwin dll's were licensed such that any programs using them had to be
GPL (or equivalent).

Is that wrong?

If so, anyone wanting to write a commercial tool has to avoid the
cygwin's core dll's.

Does using mingw do so?

Thanks
Greg

--
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: Randomly hang when compiling Cygwin on Cygwin on Wine

[Corinna Vinschen]

On Nov  2 03:08, Qian Hong wrote:
> Update:
> 
> I have another case of hang:
> 
> ?(1)-+-bash(1419290)
>  |-bash(1419318)---make(1423770)---sh(1423783)---sh(1423838)
>  |-mintty(1249269)---bash(1249277)
>  
> |-mintty(47)---bash(55)---bash(1132827)---make(1139169)---sh(1139182)---make(1139234)---sh(1206695)---sh(1206721)---make(1206764)---sh(1206770)---make(1206783)---perl(1249042)
>  |-mintty(596773)---bash(596790)---pstree(1423865)
>  `-mintty(1417449)---bash(1417457)
> 
> 
> $ ps aux | grep 1249042
>   1249042 1206783 11328271249050  pty0  197608   Oct 31 /usr/bin/perl
>   1249077 1249042 11328271249092  pty0  197608   Oct 31
> /usr/bin/nm 
> 
> 
> 
> Here the process perl(1249042) is waiting for a pipe, while its child
> process nm(1249077) is in the status "defunct". nm(1249077) appears in
> output of `ps aux`, but doesn't appear in output of `pstree -p -l`.
> 
> Is there any case, where a child process can exit unexpected, but the
> parent process still incorrectly wait for the child process forever?

I don't answer this question conclusively before consulting my lawyer.
It *might* be possible.  See fhandler_base_overlapped::close(),
fhandler_base_overlapped::check_later() and flush_async_io(), all three
in fhandler.cc.

No, I'm not happy with using overlapped IO for pipes.  I'd prefer to use
nonblocking pipes instead, but the most required resource to fix this,
which is least available, is time :(


Corinna

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


pgp6kfIM6T8sS.pgp
Description: PGP signature

Re: pthread_kill: signals remain pending after target thread exits

[Corinna Vinschen]

On Oct 29 16:16, John Carey wrote:
> > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > Sent: Thursday, October 29, 2015 1:02 AM
> > On Oct 28 10:14, Corinna Vinschen wrote:
> ...
> > > > Thanks; that was fast!  I tried replacing cygwin1.dll with 
> > > > cygwin1-20151023.dll .
> > > >
> > > > The original test case now works.  I checked some of my other tests,
> > > > and unfortunately some of them failed, so I extracted out a new test
> > > > case, which is attached.  My guess is that something is subtly different
> > > > about the timing on this test.
> > >
> > > Is this a regression?  Did it work with 2.2.1?
> > 
> > Answering myself here, this didn't work at all in 2.2.1.  I can
> > reproduce the problem and I'm going to take a look.  Not sure if
> > there's a quick solution, though.  This looks like a deadlock
> > situation.  The signal definitely got send, I just don't see yet
> > why it's not handled in wait_sig.
> 
> Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
> differ: there is no Cygwin process left hanging that cannot be
> killed by a Cygwin signal.
> 
> But both tests appear to pass in Cygwin 1.7.9, so in that sense
> it is a regression, just not a recent one.

The regression here was my original fix.  It didn't clear pending
signals for an exiting thread thorougly enough.  I applied a patch now
which should fix this issue.  I'll upload a new developer snapshot to
https://cygwin.com/snapshots/ later today or tomorrow (still looking
into the PrlFS issue).  Please give it a try.


Thanks,
Corinna

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


pgpGpEDSC_DJX.pgp
Description: PGP signature

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

[Corinna Vinschen]

On Nov  2 08:08, Jonathan Lennox wrote:
> On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
> saying:
> 
> > On Nov  2 04:38, Jonathan Lennox wrote:
> > > Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives
> > > (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is.  
> > > So I
> > > can't test hard links as administrator.
> > 
> > That's a security feature of UAC.  You can change that in the registry.
> > As administrator:
> > 
> >   regtool -d set 
> > /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections
> >  1
> > 
> > Then reboot.
> 
> Didn't work:
> 
> $ ls /cygdrive/
> c  d  e
> 
> $ regtool get 
> /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections
> 
 ^^^?

That should print "1"

EnableLinkedConnections is a DWORD value and should be set to 1.

> $ uname -a
> CYGWIN_NT-10.0 Vidyo-LT0519-10 2.3.0(0.291/5/3) 2015-11-02 11:15 x86_64 Cygwin
> 
> Is Windows 10 the same?

Yes.  Works for me.

> > I added support for this filesystem (called prlfs in mount output) and
> > without hardlink support for now.  I uploaded a new developer snapshot
> > to https://cygwin.com/snapshots/ Please give it a try.
> 
> No, still seeing the failure in the snapshot:
> 
> $ ./stat-size-test.exe /cygdrive/y/foo ~/foo
> /cygdrive/y/foo: fstat: st_size=0
> /cygdrive/y/foo: stat: st_size=12
> /home/jonathan/foo: fstat: st_size=12
> /home/jonathan/foo: stat: st_size=12

Weird.  There should be no FileNetworkOpenInformation call anymore for
Netapp and the PrlSF filesystem.

Does Cygwin correctly recognize the FS?  What does `mount' print?  It
should print `type prlfs'.

Can you please once again call `/usr/lib/csih/getVolInfo.exe Z:' and
`/usr/lib/csih/getVolInfo.exe Y:' and paste the output here?  I'm not
quite sure because the original getVolInfo call returned a filesystem
type of "PrlSF", not "PrlFS" as I had expected.  Cygwin now checks for
"PrlSF".


Corinna

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


pgp08kmGbFY5F.pgp
Description: PGP signature

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

[Jonathan Lennox]

On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
saying:

> On Nov  2 04:38, Jonathan Lennox wrote:
> > Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives
> > (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is.  So I
> > can't test hard links as administrator.
> 
> That's a security feature of UAC.  You can change that in the registry.
> As administrator:
> 
>   regtool -d set 
> /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections
>  1
> 
> Then reboot.

Didn't work:

$ ls /cygdrive/
c  d  e

$ regtool get 
/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections

$ uname -a
CYGWIN_NT-10.0 Vidyo-LT0519-10 2.3.0(0.291/5/3) 2015-11-02 11:15 x86_64 Cygwin

Is Windows 10 the same?

> I added support for this filesystem (called prlfs in mount output) and
> without hardlink support for now.  I uploaded a new developer snapshot
> to https://cygwin.com/snapshots/ Please give it a try.

No, still seeing the failure in the snapshot:

$ ./stat-size-test.exe /cygdrive/y/foo ~/foo
/cygdrive/y/foo: fstat: st_size=0
/cygdrive/y/foo: stat: st_size=12
/home/jonathan/foo: fstat: st_size=12
/home/jonathan/foo: stat: st_size=12

$ uname -a
CYGWIN_NT-10.0 Vidyo-LT0519-10 2.3.0(0.291/5/3) 2015-11-02 11:15 x86_64 Cygwin

(See https://cygwin.com/ml/cygwin/2014-04/msg00488.html for the source code
to stat-size-test.c).

Oddly, though, the original problematic behavior I saw in emacs (with it
falsely detecting files as being modified externally) has gone away. Maybe
emacs added a workaround for this?

-- 
Jonathan Lennox
len...@cs.columbia.edu

--
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: fstat st_size on open files on Parallels filesystem is wrong

[cyg Simple]

On 11/2/2015 4:38 AM, Jonathan Lennox wrote:
> 
> Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives
> (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is.  So I
> can't test hard links as administrator.
> 

This is due to "Run As Administrator" is a different user with a
different environment.  You would need to recreate the mapped drives.

-- 
cyg 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: compile ncurses "hello world" to run independent of cygwin?

[cyg Simple]

On 11/1/2015 11:09 PM, Darik Horn wrote:
> 
> Unless there is a specific reason to cross through Cygwin, it could be
> easier to use the native MinGW environment directly:
> 
> * http://www.mingw.org/wiki/Getting_Started
> 

Poppycock! There is no reason that the user couldn't use Cygwin as the
one and only system to build native binaries.

> And link against the ncurses redistributable:
> 
> * http://invisible-mirror.net/ncurses/ncurses.html
> 

Building your own native library with a known set of compilers and
options may be better than depending on someone's build where you don't
know for certain the system, options and compiler used.

-- 
cyg 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: compile ncurses "hello world" to run independent of cygwin?

[cyg Simple]

On 11/1/2015 10:04 PM, Daniel Goldman wrote:
> 
> $ gcc ncurses-1.c -lncurses
> 
> $ ./a.exe # runs perfectly under cygwin
> 

A Cygwin build using the Cygwin runtime should work.

> $ i686-pc-mingw32-gcc -I /usr/include ncurses-1.c -L /lib -lncurses
> 
> $ ./a.exe
> Segmentation fault
> 

A MinGW build using the Cygwin runtime should *never* work.

> 
> What am I doing wrong? How do I use cygwin to compile the test ncurses
> program so it can run in a dos terminal, independent of cygwin? I looked
> around the docs and archives and could not figure out.
> 

You need to specify include and lib paths that contain MinGW libraries.
 Don't use the Cygwin native paths of /usr/include and /lib.  This means
that you need a ncurses library that is built with MinGW.

-- 
cyg 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: Help: cygheap base mismatch detected

[Corinna Vinschen]

On Nov  1 17:22, Jim Reisert AD1C wrote:
> I installed the latest Windows 10 update this morning and rebooted.
> Now Cygwin won't work at all.  Using the latest test release of
> Cygwin:
> 
> CYGWIN_NT-10.0-WOW JJR 2.3.0(0.291/5/3) 2015-10-22 17:54 i686 Cygwin
> 
> Any ideas?
> 
> F:\>dash
> $  rebase-trigger fullrebase
>   0 [main] dash (4564) C:\Cygwin\bin\dash.exe: *** fatal error -
> cygheap base mismatch detected - 0xABB400/0xD1B400.

*Both* addresses are wrong.  The 32 bit Cygwin DLL has to be loaded to
address 0x6100 (as noted in the file header) which, if done correctly,
results in a cygheap address > 0x6100.  The cygheap is part of the
DLL binary, so it's loaded with it.  In Cygwin 2.2.1, the address should
be in the 0x612fc000 range.

It seems a Windows DLL or a virus scanner DLL gets loaded to this
address for some reason.  I'm a bit at a loss to make a suggestion here,
except for switching to 64 bit Cygwin which has much less problems with
this due to the huge address space.


Corinna

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


pgpG1ZCRaicYb.pgp
Description: PGP signature

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

[Corinna Vinschen]

On Nov  2 04:38, Jonathan Lennox wrote:
> On Wednesday, October 21 2015, "Corinna Vinschen" wrote to 
> "cygwin@cygwin.com" saying:
> > On Oct  8 12:16, Jonathan Lennox wrote:
> > > 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?
> 
> I re-ran the test, no change. Changing the order gives the same result --
> FileStandardInformation works, FileNetworkOpenInformation doesn't.

Ok, so it's not about some caching.

> > 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:
> 
> "You do not have sufficient privilege to perform this operation."  Is that
> sufficient proof?

No.

> Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives
> (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is.  So I
> can't test hard links as administrator.

That's a security feature of UAC.  You can change that in the registry.
As administrator:

  regtool -d set 
/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections
 1

Then reboot.

> >   $ 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.
> 
> However, when I create a hardlink on the underlying (Mac) file system, the
> inode numbers that Cygwin shows are not identical.  So "no hardlinks" seems
> very likely.

Given the filesystem flags, Cygwin treats your FS as some kind of FAT
anyway, so this isn't convincing.  I doubt they work anyway, but if you
really want to test it, use your orignal testcase and replace the
NtQueryInformationFile like this:

  FILE_INTERNAL_INFORMATION fii;
  status = NtQueryInformationFile (h, &io, &fii, sizeof fii,
   FileInternalInformation);
  if (!NT_SUCCESS (status))
fprintf (stderr, "NtQueryInformationFile: 0x%08x\n", status);
  else
printf ("inode number %llu\n", fii.FileId.QuadPart);

Then call this application multiple times on some well known hardlinks
to the same file.  If they have the same number, all the time, hardlinks
work.

I added support for this filesystem (called prlfs in mount output) and
without hardlink support for now.  I uploaded a new developer snapshot
to https://cygwin.com/snapshots/ Please give it a try.


Thanks,
Corinna

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


pgpEsjMhEKvUb.pgp
Description: PGP signature

Re: Mounting a network share

[Corinna Vinschen]

On Nov  1 23:35, Mike Brown wrote:
> On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
> > net use //host/resource[/path] P: * /PERSISTENT /SAVECRED
> 
> I got the following to be accepted:
> 
> net use \\192.168.1.40\Public password /user:brown /persistant:yes
> 
> The syntax doesn't have a place to where it should be mounted.
> 
> But, if it mounted, I have no idea where. A "df -k" only shows the local 
> drives.
> 
> > This is not a Cygwin question.
> > If you want to do it from Cygwin side, use fstab and don't use /cygdrive
> > prefix. It is for automatic mounts ONLY.
> 
> I can't find a fstab.

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


Corinna

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


pgpv0Ob49h8IJ.pgp
Description: PGP signature

Re: TP_NUM_C_BUFS too small

[Corinna Vinschen]

On Nov  2 02:32, Mark Geisert wrote:
> Helmut Karlowski writes:
> > Am 01.11.2015, 18:46 Uhr, schrieb Helmut Karlowski:
> > > Hello
> > >
> > > just had a program crashing with this error:
> > >
> > >   2 [main] ue 3180 C:\bin\ue.exe: *** fatal error - Internal error:  
> > > TP_NUM_C_BUFS too small: 50
> > >
> > > What could that mean?
> > 
> > It means my program had a bug - fixed now.
> 
> Glad it's fixed!  For the record, could you say what sort of bug would cause
> a fatal internal error like that?
> Just curious,

Me too.  Sounds like some kind of recursion.


Corinna

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


pgpk80CaCON0w.pgp
Description: PGP signature

Re: Bug in collation functions?

[Corinna Vinschen]

On Oct 31 13:13, Ken Brown wrote:
> On 10/30/2015 10:07 AM, Ken Brown wrote:
> >Hi Corinna,
> >
> >On 10/30/2015 8:03 AM, Corinna Vinschen wrote:
> >>On Oct 29 18:21, Ken Brown wrote:
> >>>The fallback I had in mind is to return the shorter string if they have
> >>>different lengths and otherwise to revert to wcscmp.
> > >
> >>I had a longer look into this suggestion and the below code and it took
> >>me some time to find out what bugged me with it:
> >>
> >>What about str/wcsxfrm?
> >>
> >>Per POSIX, calling strcmp on the result of strxfrm is equivalent to
> >>calling strcoll (analogue with wcs*).  If you extend *coll to perform an
> >>extra check on the length, you will have cases in which the above rule
> >>fails.  You can't perform the length test on the result of *xfrm and
> >>expect the same result as in *coll.
> >>
> >>In fact, when calling LCMapStringW with NORM_IGNORESYMOLS (you would
> >>have to do this anyway if we add this flag in *coll), the resulting
> >>transformed strings created from the input strings "11" and "1.1" would
> >>be identical, so a length test on the xfrm string is not meaningful at
> >>all.
> >>
> >>The bottom line is, afaics, we must make sure that CompareStringW and
> >>LCMapStringW are called the same way, and their result/output has to be
> >>returned to the caller.  Performing an extra check in *coll which can't
> >>be reliably performed in *xfrm is not feasible.
> >>
> >>Does that make sense?
> >
> >Yes, I see the problem, and I don't see a good way around it.  So I
> >think we probably have to leave things as they are and live with the
> >fact that we can't do comparisons that ignore whitespace and punctuation.
> >
> >The alternative of allowing str/wcscoll to return 0 on unequal strings
> >doesn't seem feasible in view of Eric's comments.
> 
> I have one other idea.  What would you think of defining a function
> cygwin_strcoll that's like strcoll but with an extra bool parameter
> 'ignoresymbols'?  If ignoresymbols = false, this would be the same as
> strcoll.  If ignoresymbols = true, this would use NORM_IGNORESYMBOLS with
> the fallback I suggested.
> 
> That way applications that prefer to be more glibc-compatible and don't need
> strxfrm could do something like
> 
>   #define strcoll(A,B) cygwin_strcoll ((A), (B), true)
> 
> If you think this is reasonable, I'll submit a patch.  If not, no problem.

No, I don't think this is feasible.  Given Eric's comments, can an
application ever expect that strcoll behaves exactly as on Linux?  For
portability reasons, it has to expect different results on different
platforms.  Only if the result is POSIXly incorrect, it makes sense to
fix the behaviour, IMHO.


Corinna

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


pgpXbwJhLF_MI.pgp
Description: PGP signature

Re: Pop up GUI remotely via SSH

[trimat]

@Larry thanks for the answer.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Pop-up-GUI-remotely-via-SSH-tp122269p122467.html
Sent from the Cygwin list mailing list archive at Nabble.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: fstat st_size on open files on Parallels filesystem is wrong

[Jonathan Lennox]

On Wednesday, October 21 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
saying:

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

I re-ran the test, no change. Changing the order gives the same result --
FileStandardInformation works, FileNetworkOpenInformation doesn't.

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

"You do not have sufficient privilege to perform this operation."  Is that
sufficient proof?

Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives
(/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is.  So I
can't test hard links as administrator.

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

However, when I create a hardlink on the underlying (Mac) file system, the
inode numbers that Cygwin shows are not identical.  So "no hardlinks" seems
very likely.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: zsh-5.1.1-1

[Ismail Donmez]

Hi,

Peter A. Castro  fruitbat.org> writes:

> 
> An updated version of zsh (zsh-5.1.1-1) has been released and should be
> at a mirror near you real soon.  This is an upstream release.

Thank you!



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