Re: WSL symbolic links
Thomas Wolff writes: >> - Last but not least, could you please create a symlink pointing to a >>target with a non-ASCII char, e. g., some german umlaut? > Not sure what kind of remote you'd like to see. I have a 'net use' > (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise: That's exactly why WSL is so nearly useless to me and why Cygwin continues to hold its place. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACL: Why SYSTEM doesn't have full access set on newly created files?
Same issue here. I use git in msys2 for correct file permissions. Also
if I install cygwin and reinstall Windows 10 OS then Windows programs
can not edit any cygwin files. I have to take ownership with takeown
and icacls commands then chmod the files.
I found a temporary workaround. 1. Add `noacl` option in `/etc/fstab`
file in cygwin. But this only fixes the file permission in Windows
drives . 2. In newlib-cygwin source code, remove
`FILE_PERSISTENT_ACLS` flag and add `MOUNT_NOACL` flag in
winsup/cygwin/mount.cc file. Attached patch file as reference.
diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc
index e034981..7ba6f4a 100644
--- a/winsup/cygwin/mount.cc
+++ b/winsup/cygwin/mount.cc
@@ -332,7 +332,6 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol)
#define MINIMAL_WIN_NTFS_FLAGS (FILE_CASE_SENSITIVE_SEARCH \
| FILE_CASE_PRESERVED_NAMES \
| FILE_UNICODE_ON_DISK \
- | FILE_PERSISTENT_ACLS \
| FILE_FILE_COMPRESSION \
| FILE_VOLUME_QUOTAS \
| FILE_SUPPORTS_SPARSE_FILES \
@@ -473,13 +472,13 @@ mount_info::create_root_entry (const PWCHAR root)
sys_wcstombs (native_root, PATH_MAX, root);
assert (*native_root != '\0');
if (add_item (native_root, "/",
- MOUNT_SYSTEM | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC)
+ MOUNT_SYSTEM | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC | MOUNT_NOACL)
< 0)
api_fatal ("add_item (\"%s\", \"/\", ...) failed, errno %d", native_root,
errno);
/* Create a default cygdrive entry. Note that this is a user entry.
This allows to override it with mount, unless the sysadmin created
a cygdrive entry in /etc/fstab. */
- cygdrive_flags = MOUNT_NOPOSIX | MOUNT_CYGDRIVE;
+ cygdrive_flags = MOUNT_NOPOSIX | MOUNT_CYGDRIVE | MOUNT_NOACL;
strcpy (cygdrive, CYGWIN_INFO_CYGDRIVE_DEFAULT_PREFIX "/");
cygdrive_len = strlen (cygdrive);
}
@@ -508,12 +507,12 @@ mount_info::init (bool user_init)
if (!got_usr_bin)
{
stpcpy (p, "\\bin");
- add_item (native, "/usr/bin", MOUNT_SYSTEM | MOUNT_AUTOMATIC);
+ add_item (native, "/usr/bin", MOUNT_SYSTEM | MOUNT_AUTOMATIC |
MOUNT_NOACL);
}
if (!got_usr_lib)
{
stpcpy (p, "\\lib");
- add_item (native, "/usr/lib", MOUNT_SYSTEM | MOUNT_AUTOMATIC);
+ add_item (native, "/usr/lib", MOUNT_SYSTEM | MOUNT_AUTOMATIC |
MOUNT_NOACL);
}
}
}
@@ -1131,7 +1130,7 @@ mount_info::from_fstab_line (char *line, bool user)
return true;
cend = find_ws (c);
*cend = '\0';
- unsigned mount_flags = MOUNT_SYSTEM;
+ unsigned mount_flags = MOUNT_SYSTEM | MOUNT_NOPOSIX | MOUNT_NOACL;
if (!strcmp (fs_type, "cygdrive"))
mount_flags |= MOUNT_NOPOSIX;
if (!strcmp (fs_type, "usertemp"))
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
ACL: Why SYSTEM doesn't have full access set on newly created files?
Hi, I know that Cygwin tries to emulate UNIX permissions using ACL. But I don't understand why SYSTEM doesn't have Full Control allowed or even modify. Shouldn't generally SYSTEM have access to everything? I have cloned git repository of UWP application, and deployment fails in VS with error: "DEP0700: Registration of the app failed. [0x80070005] Deployment Register operation with target volume F: on Package ... from: (AppxManifest.xml) failed with error 0x80070005." It is easily fixable by adding Full Control for SYSTEM on all files, but that wasn't my first idea, so it took some time :) Long story short, it fails and might be not obvious for the user why, at the first glance. Also when accessing ACL from Explorer it throws: "The permissions on are incorrectly ordered, which may cause some entries to be ineffective." And forces me to reorder them if I want to edit. That said, I have three questions: 1. Could Cygwin by default give SYSTEM full control? If not, why? 2. Could Cygwin put ACL in order, so Windows doesn't complain about it? 3. Do we need "NULL SID" entry? -Kacper -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Am 26.03.2020 um 20:56 schrieb Corinna Vinschen: Brian and Thomas, Thanks to both of you for providing this info. On Mar 26 13:12, Brian Inglis wrote: On 2020-03-26 05:00, Corinna Vinschen wrote: On Mar 26 10:00, Thomas Wolff wrote: A symbolic link created with WSL is neither interpreted in cygwin nor can it be deleted: touch file wsl ln -s file link wsl ls -l link lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file ls -l link -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link What kind of file are they in the real world? Reparse points? If so, what content do they have? I attached a Q source from my vault of old test apps to check on reparse point content. Please compile with gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll It takes a single native NT path as parameter, kind of like this: ./rd-reparse '\??\C:\cygwin64\home\corinna\link' They should be WSL or Windows mklink (soft) links, and the reason why mklink was allowed unelevated in Windows 10 with Developer mode. In an *elevated* shell: $ ls -dln u -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u $ getfacl u getfacl: u: Permission denied $ icacls u u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) $HOSTNAME\$USER:(F) $HOSTNAME\$USER:(RX,W,DC) BUILTIN\Users:(Rc,S,RA) BUILTIN\Administrators:(RX,W,DC) BUILTIN\Users:(DENY)(S,RD,REA,X) Everyone:(RX) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) $HOSTNAME\$USER:(I)(F) Successfully processed 1 files; Failed processing 0 files $ ./rd-reparse '\??\C:\...\u' ReparseTag: 0xa01d ^^ This is a reparse point tag different from the normal Windows symlink reparse point tag, 0xa00c. Searching for this value shows this is defined in ntifs.h as IO_REPARSE_TAG_LX_SYMLINK. Unfortunately I don't see a definition of the reparse point data for that reparse point type. In your examples the data part looks like a 4 byte int value, being 2 in both of your examples, maybe a file type, followed by the path in multibyte, no trailing \0. Unfortunately, in both cases the path is relative, just the file name it points to. To get more information, could one of you two please create a few more symlinks? - A symlink pointing to a local path, given in absolute path syntax. I assume the path will be in POSIX syntax, contain slashes, but it would be helpful to see it. - A symlink with a target path pointing to a remote file (what syntax does this use?) - Last but not least, could you please create a symlink pointing to a target with a non-ASCII char, e. g., some german umlaut? Not sure what kind of remote you'd like to see. I have a 'net use' (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise: > wsl -d Ubuntu ls -l link* lrwxrwxrwx 1 towo towo 4 Mar 27 00:31 link -> file lrwxrwxrwx 1 towo towo 15 Mar 27 00:31 link-abs -> /mnt/c/tmp/file lrwxrwxrwx 1 towo towo 5 Mar 27 00:39 link-foo -> föö lrwxrwxrwx 1 towo towo 16 Mar 27 00:39 link-foo-abs -> /mnt/c/tmp/föö > rd-reparse '\??\C:\tmp\link' ; echo ReparseTag: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 > rd-reparse '\??\C:\tmp\link-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 19 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 69 6c 65 > rd-reparse '\??\C:\tmp\link-foo' ; echo ReparseTag: 0xa01d ReparseDataLength: 9 Reserved: 0 02 00 00 00 66 c3 b6 c3 b6 > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 20 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 c3 b6 c3 b6 > If the link name itself contains non-ASCII, rd-reparse fails with NtOpenFile: C034 It's questionable if supporting this new symlink type makes sense, but taking a closer look doesn't hurt, I guess. Well, at least they should be deletable, I think. Thomas Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: Named pipes and multiple writers
On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote:
The ENIXIO occurs when parallel child-processes simultaneously using
O_NONBLOCK opening the descriptor.
This is consistent with my guess that the error is generated by
fhandler_fifo::wait. I have a feeling that read_ready should have been created
as a manual-reset event, and that more care is needed to make sure it's set when
it should be.
I could provide a code-snippet
to reproduce it if wanted ?
Yes, please!
That might not be necessary. If you're able to build the git repo master
branch, please try the attached patch.
Ken
>From 279591d91a13616957964256e02344a627b6f558 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Thu, 26 Mar 2020 19:02:16 -0400
Subject: [PATCH] Cygwin: FIFO: make read_ready a manual-reset event
If a FIFO is open for reading and an attempt is made to open it for
writing with O_NONBLOCK, read_ready must be set in order for open to
succeed. When read_ready was an auto-reset event, there was a brief
period when read_ready was not set set after a writer opened. If a
second writer attempted to open the FIFO with O_NONBLOCK during this
period, the attempt would fail.
Addresses: https://sourceware.org/pipermail/cygwin/2020-March/244201.html
---
winsup/cygwin/fhandler_fifo.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 19cd0e507..c05161099 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -516,7 +516,7 @@ fhandler_fifo::open (int flags, mode_t)
char npbuf[MAX_PATH];
__small_sprintf (npbuf, "r-event.%08x.%016X", get_dev (), get_ino ());
- if (!(read_ready = CreateEvent (sa_buf, false, false, npbuf)))
+ if (!(read_ready = CreateEvent (sa_buf, true, false, npbuf)))
{
debug_printf ("CreateEvent for %s failed, %E", npbuf);
res = error_set_errno;
--
2.21.0
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Use cygwin to run autotools for MSVC?
On 3/26/2020 5:37 PM, Csaba Raduly via Cygwin wrote: Hi Mike, On Thu, Mar 26, 2020 at 9:31 PM Mike Gran via Cygwin wrote: Hi- Is it possible use Cygwin to run an autotools 'configure' script but have the compiler be MSVC? I would be very surprised if this worked. 'configure' is likely to run the compiler with unix-style flags (started with hyphens) rather than DOS-style flags (started with forward slashes). cl.exe may accept only DOS-style flags. Also, MSVC won't be able to find Cygwin's include files, and even if it did, most likely won't be able to compile them. The whole thing sounds like a recipe for failure. What are you trying to achieve? All that said, I _have_ seen build processes organized to give MSVC as an option ... and that in fact sometimes make it hard to do a Cygwin build because they "want" to do a native Windows build! However, this may have been more just a canned Makefile than a whole ./configure process ... Eliot -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: Named pipes and multiple writers
On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote: The ENIXIO occurs when parallel child-processes simultaneously using O_NONBLOCK opening the descriptor. This is consistent with my guess that the error is generated by fhandler_fifo::wait. I have a feeling that read_ready should have been created as a manual-reset event, and that more care is needed to make sure it's set when it should be. I could provide a code-snippet to reproduce it if wanted ? Yes, please! Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Sv: Sv: Named pipes and multiple writers
>> [snip] As far as I can see, reading through history, this have been a known issue for quite some time, but it seems like there have been some attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown) >> >> [snip] Does anyone have any knowledge about if this (topic/fifo branch) is working and/or if it is somehow planned to make it into the master branch and end up in a future release ? >> >>> That branch is obsolete. Support for multiple writers was added to >>> Cygwin >> as of release 3.1.0. >> >> Ok, thanks, but we're running 3.1.4 (and tested 3.1.5) but do still >> have problems (experiencing ENXIO (No such device or address)) but >> actually (as far as we see) with the 3:rd writer ? >> >> We need to investigate the issue more thoroughly and might get back >> when we have more knowledge >Does the ENXIO come from fhandler_fifo::wait? If so, it's quite possible that there's a bug involving read_ready in my code. Our application is a bit complex and I have now narrowed it down The ENIXIO occurs when parallel child-processes simultaneously using O_NONBLOCK opening the descriptor. We're sometimes opening it blocking and sometimes non-blocking and it seems like when the 2:nd non-blocking process tries to open it gets ENIXIO. The child process open and closes the fifo-descriptor for writing multiple times. I could provide a code-snippet to reproduce it if wanted ? Tnx for showing interest btw Kristian >Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Use cygwin to run autotools for MSVC?
Hi Mike, On Thu, Mar 26, 2020 at 9:31 PM Mike Gran via Cygwin wrote: > Hi- > Is it possible use Cygwin to run an autotools 'configure' script but have > the compiler be MSVC? > I would be very surprised if this worked. 'configure' is likely to run the compiler with unix-style flags (started with hyphens) rather than DOS-style flags (started with forward slashes). cl.exe may accept only DOS-style flags. Also, MSVC won't be able to find Cygwin's include files, and even if it did, most likely won't be able to compile them. The whole thing sounds like a recipe for failure. What are you trying to achieve? Csaba -- You can get very substantial performance improvements by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler So if you're looking for a completely portable, 100% standards-conformant way to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN or rebuilt for perl-5.30, respectively: x86/x86_64 -- perl-Alien-wxWidgets-0.69-2 perl-Cairo-1.107-3 perl-Cairo-GObject-1.005-1 perl-Font-FreeType-0.13-1 perl-Glib-1.3292-1 perl-Glib-Object-Introspection-0.048-1 perl-Gnome2-1.047-1 perl-Gnome2-Canvas-1.002-14 perl-Gnome2-GConf-1.044-14 perl-Gnome2-Rsvg-0.11-4 perl-Gnome2-VFS-1.083-2 perl-Gnome2-Vte-0.11-4 perl-Gnome2-Wnck-0.16-14 perl-Gtk2-1.24993-1 perl-Gtk2-GladeXML-1.007-14 perl-Gtk2-Notify-0.05-14 perl-Gtk2-SourceView2-0.10-5 perl-Gtk2-Spell-1.04-4 perl-Gtk2-Unique-0.05-5 perl-Gtk2-WebKit-0.09-4 perl-Pango-1.227-3 perl-Win32-GUI-1.14-2 perl-Wx-0.9932-2 noarch -- perl-GStreamer1-0.003-3 perl-Gtk3-0.037-1 perl-Test-Fork-0.02-1 -- *** 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@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: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN or rebuilt for perl-5.30, respectively: x86/x86_64 -- perl-Alien-wxWidgets-0.69-2 perl-Cairo-1.107-3 perl-Cairo-GObject-1.005-1 perl-Font-FreeType-0.13-1 perl-Glib-1.3292-1 perl-Glib-Object-Introspection-0.048-1 perl-Gnome2-1.047-1 perl-Gnome2-Canvas-1.002-14 perl-Gnome2-GConf-1.044-14 perl-Gnome2-Rsvg-0.11-4 perl-Gnome2-VFS-1.083-2 perl-Gnome2-Vte-0.11-4 perl-Gnome2-Wnck-0.16-14 perl-Gtk2-1.24993-1 perl-Gtk2-GladeXML-1.007-14 perl-Gtk2-Notify-0.05-14 perl-Gtk2-SourceView2-0.10-5 perl-Gtk2-Spell-1.04-4 perl-Gtk2-Unique-0.05-5 perl-Gtk2-WebKit-0.09-4 perl-Pango-1.227-3 perl-Win32-GUI-1.14-2 perl-Wx-0.9932-2 noarch -- perl-GStreamer1-0.003-3 perl-Gtk3-0.037-1 perl-Test-Fork-0.02-1 -- *** 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@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.
Use cygwin to run autotools for MSVC?
Hi- Is it possible use Cygwin to run an autotools 'configure' script but have the compiler be MSVC? Thanks, Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
On Mar 26 13:12, Brian Inglis wrote: > On 2020-03-26 05:00, Corinna Vinschen wrote: > > On Mar 26 10:00, Thomas Wolff wrote: > >> A symbolic link created with WSL is neither interpreted in cygwin nor can > >> it > >> be deleted: > >>> touch file > >>> wsl ln -s file link > >>> wsl ls -l link > >> lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file > >>> ls -l link > >> -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > > What kind of file are they in the real world? Reparse points? If so, > > what content do they have? I attached a Q source from my vault > > of old test apps to check on reparse point content. Please compile with > > gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll > > It takes a single native NT path as parameter, kind of like this: > > ./rd-reparse '\??\C:\cygwin64\home\corinna\link' > > They should be WSL or Windows mklink (soft) links, and the reason why mklink > was > allowed unelevated in Windows 10 with Developer mode. > > In an *elevated* shell: > > $ ls -dln u > -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u ^ This is unknown user, unknown group, which means, the Windows function LookupAccountSid() probably returned a domain name which is unknown (neither account domain, nor primary, nor trusted domain). An strace of `ls -l u' may be helpful... > $ getfacl u > getfacl: u: Permission denied > $ icacls u > u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) > $HOSTNAME\$USER:(F) ^^^ Is that the *real* output, or did you tamper with it? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Brian and Thomas, Thanks to both of you for providing this info. On Mar 26 13:12, Brian Inglis wrote: > On 2020-03-26 05:00, Corinna Vinschen wrote: > > On Mar 26 10:00, Thomas Wolff wrote: > >> A symbolic link created with WSL is neither interpreted in cygwin nor can > >> it > >> be deleted: > >>> touch file > >>> wsl ln -s file link > >>> wsl ls -l link > >> lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file > >>> ls -l link > >> -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > > What kind of file are they in the real world? Reparse points? If so, > > what content do they have? I attached a Q source from my vault > > of old test apps to check on reparse point content. Please compile with > > gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll > > It takes a single native NT path as parameter, kind of like this: > > ./rd-reparse '\??\C:\cygwin64\home\corinna\link' > > They should be WSL or Windows mklink (soft) links, and the reason why mklink > was > allowed unelevated in Windows 10 with Developer mode. > > In an *elevated* shell: > > $ ls -dln u > -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u > $ getfacl u > getfacl: u: Permission denied > $ icacls u > u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) > $HOSTNAME\$USER:(F) > $HOSTNAME\$USER:(RX,W,DC) > BUILTIN\Users:(Rc,S,RA) > BUILTIN\Administrators:(RX,W,DC) > BUILTIN\Users:(DENY)(S,RD,REA,X) > Everyone:(RX) > NT AUTHORITY\SYSTEM:(I)(F) > BUILTIN\Administrators:(I)(F) > $HOSTNAME\$USER:(I)(F) > > Successfully processed 1 files; Failed processing 0 files > $ ./rd-reparse '\??\C:\...\u' > ReparseTag: 0xa01d ^^ This is a reparse point tag different from the normal Windows symlink reparse point tag, 0xa00c. Searching for this value shows this is defined in ntifs.h as IO_REPARSE_TAG_LX_SYMLINK. Unfortunately I don't see a definition of the reparse point data for that reparse point type. In your examples the data part looks like a 4 byte int value, being 2 in both of your examples, maybe a file type, followed by the path in multibyte, no trailing \0. Unfortunately, in both cases the path is relative, just the file name it points to. To get more information, could one of you two please create a few more symlinks? - A symlink pointing to a local path, given in absolute path syntax. I assume the path will be in POSIX syntax, contain slashes, but it would be helpful to see it. - A symlink with a target path pointing to a remote file (what syntax does this use?) - Last but not least, could you please create a symlink pointing to a target with a non-ASCII char, e. g., some german umlaut? It's questionable if supporting this new symlink type makes sense, but taking a closer look doesn't hurt, I guess. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
On 2020-03-26 05:00, Corinna Vinschen wrote: > On Mar 26 10:00, Thomas Wolff wrote: >> A symbolic link created with WSL is neither interpreted in cygwin nor can it >> be deleted: >>> touch file >>> wsl ln -s file link >>> wsl ls -l link >> lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file >>> ls -l link >> -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > What kind of file are they in the real world? Reparse points? If so, > what content do they have? I attached a Q source from my vault > of old test apps to check on reparse point content. Please compile with > gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll > It takes a single native NT path as parameter, kind of like this: > ./rd-reparse '\??\C:\cygwin64\home\corinna\link' They should be WSL or Windows mklink (soft) links, and the reason why mklink was allowed unelevated in Windows 10 with Developer mode. In an *elevated* shell: $ ls -dln u -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u $ getfacl u getfacl: u: Permission denied $ icacls u u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) $HOSTNAME\$USER:(F) $HOSTNAME\$USER:(RX,W,DC) BUILTIN\Users:(Rc,S,RA) BUILTIN\Administrators:(RX,W,DC) BUILTIN\Users:(DENY)(S,RD,REA,X) Everyone:(RX) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) $HOSTNAME\$USER:(I)(F) Successfully processed 1 files; Failed processing 0 files $ ./rd-reparse '\??\C:\...\u' ReparseTag: 0xa01d ReparseDataLength: 5 Reserved: 0 02 00 00 00 75 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Why didn't a Cygwin install create the default dot files?
Greetings, David Karr! > I've been using Cygwin for a long time. I haven't run a fresh install for > quite a while. > A colleague just installed Cygwin for the first time, following my basic > instructions. He ended up with his Cygwin home being the same as his > Windows home, which is different from my setup, but I think that's fine. This suggests something in the environment. Possibly your colleague have %HOME% defined. Cygwin will pick it up. > What seems odd is that he didn't get the default dot files created, being > .profile, .bash_profile, and .bashrc. > I don't even remember whether this happened the first time I set it up. In > any case, I handed him my dot files to template from, but I was curious > about that process. These are only copied to profile, when a new profile directory is created. I.e. if there's no HOME env. var set and Cygwin is with default nsswitch configuration. You can find Cygwin default profile in the usual place. /etc/skel, that is. -- With best regards, Andrey Repin Thursday, March 26, 2020 21:56:38 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: "tmux open terminal failed: not a terminal" in terminal emulators other than mintty
Greetings, Kacper Michajlow! > I'm not exactly sure who to blame for this issue, but I figured I will ask > you guys. Tmux fails to open in anything else than mintty it seems like. It > works from ssh session, probably because pseudo-tty is allocated, but except > that tmux will fail. > There are multiple reports about that, without solutions: > https://github.com/cmderdev/cmder/issues/453 > https://github.com/alacritty/alacritty/issues/1687 > https://github.com/zeit/hyper/issues/3608 > https://github.com/microsoft/terminal/issues/5132 > Do you think we could make it work without using mintty? You can try another pty emulator. F.e. wintty. > If yes, should the changes be made in the Cygwin, tmux or terminal emulator > code? > Any pointer would be good so I can poke others :) -- With best regards, Andrey Repin Thursday, March 26, 2020 22:02:58 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
"tmux open terminal failed: not a terminal" in terminal emulators other than mintty
Hi, I'm not exactly sure who to blame for this issue, but I figured I will ask you guys. Tmux fails to open in anything else than mintty it seems like. It works from ssh session, probably because pseudo-tty is allocated, but except that tmux will fail. There are multiple reports about that, without solutions: https://github.com/cmderdev/cmder/issues/453 https://github.com/alacritty/alacritty/issues/1687 https://github.com/zeit/hyper/issues/3608 https://github.com/microsoft/terminal/issues/5132 Do you think we could make it work without using mintty? If yes, should the changes be made in the Cygwin, tmux or terminal emulator code? Any pointer would be good so I can poke others :) Thanks, Kacper -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Why didn't a Cygwin install create the default dot files?
I've been using Cygwin for a long time. I haven't run a fresh install for quite a while. A colleague just installed Cygwin for the first time, following my basic instructions. He ended up with his Cygwin home being the same as his Windows home, which is different from my setup, but I think that's fine. What seems odd is that he didn't get the default dot files created, being .profile, .bash_profile, and .bashrc. I don't even remember whether this happened the first time I set it up. In any case, I handed him my dot files to template from, but I was curious about that process. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Named pipes and multiple writers
On 3/26/2020 12:44 PM, Ken Brown via Cygwin wrote: On 3/26/2020 12:03 PM, Norton Allen wrote: On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote: BTW, I've been working on adding support for multiple readers. I expect to have a first cut ready within a week or two. Would you have any use for that? If so, I could revive the topic/fifo branch and push my patches there for you to test. Ken, what are the semantics for multiple readers? Do all readers see the same data, or is it first come first served or something else? It's first come, first served. If two readers attempt to read simultaneously, it's possible that one will get some of the available input and the other will get some more. The only use case for multiple readers that I've come across of is Midnight Commander running under tcsh. I didn't dig into the code enough to know why they do it, or why only under tcsh. See https://sourceware.org/pipermail/cygwin/2019-December/243317.html and https://cygwin.com/pipermail/cygwin-apps/2019-December/039777.html That's what got me interested in this. It would be nice to know if there are other use cases. I suppose it could be used as a simple approach to deploying jobs to worker processes, provided a process could guarantee that it received enough information to define a job and not more than one. I guess if the job definition were fixed length that could work. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Named pipes and multiple writers
On 3/26/2020 12:03 PM, Norton Allen wrote: On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote: BTW, I've been working on adding support for multiple readers. I expect to have a first cut ready within a week or two. Would you have any use for that? If so, I could revive the topic/fifo branch and push my patches there for you to test. Ken, what are the semantics for multiple readers? Do all readers see the same data, or is it first come first served or something else? It's first come, first served. If two readers attempt to read simultaneously, it's possible that one will get some of the available input and the other will get some more. The only use case for multiple readers that I've come across of is Midnight Commander running under tcsh. I didn't dig into the code enough to know why they do it, or why only under tcsh. See https://sourceware.org/pipermail/cygwin/2019-December/243317.html and https://cygwin.com/pipermail/cygwin-apps/2019-December/039777.html That's what got me interested in this. It would be nice to know if there are other use cases. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Am 26.03.2020 um 12:00 schrieb Corinna Vinschen: On Mar 26 10:00, Thomas Wolff wrote: A symbolic link created with WSL is neither interpreted in cygwin nor can it be deleted: touch file wsl ln -s file link wsl ls -l link lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file ls -l link -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link What kind of file are they in the real world? Reparse points? If so, what content do they have? I attached a Q source from my vault of old test apps to check on reparse point content. Please compile with gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll It takes a single native NT path as parameter, kind of like this: ./rd-reparse '\??\C:\cygwin64\home\corinna\link' output is: ReparseTag: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problems with cursor position and hotkey commands in nano v.4.3
On 2020-03-26 06:38, Fergus Daly via Cygwin wrote: >>> Anybody else having problems with cursor position and hotkey commands in >>> nano v.4.3? > > Further to above, and a bit different: > I downloaded the current nano-4.9.tgz from source, extracted the source files > and within Cygwin ran the > ./configure .. .. make .. .. make install trio. > Perfect glich-free installation showing the new nano executable and support > files located in /usr/local/bin/ and /usr/local/share/. > (NB the Cygwin-provided nano v.4.3 installation remains in place.) > The command > $ echo $PATH > returns > /home/user/bin:/usr/local/bin:/usr/X11R6/bin:/usr/bin:/sbin:/usr/sbin > (so /usr/local/bin/ precedes /usr/bin/ as required) > and the command > # which nano > returns > /usr/local/bin/nano > (as expected) > BUT: the command > $ nano --version > returns > GNU nano, version 4.3 > which is not what is required, referring to the original and not the later > installation; and the command > $ nano anynamedtextfile > reveals on screen that nano v.4.3 not v.4.9 is being used. > Q1 Am I doing / thinking / remembering something daft about command > hierarchies, or should the expected v.4.9 be the one obtained (which it > isn't)? > Q2 Should I _necessarily_ uninstall the original v.4.3 - and if so, why, > given the expected priority usages? > Thank you! If using bash as your SHELL, enter: $ command -V nano # lists what will execute $ type -a nano # lists aliases, functions, exes in PATH and it should tell you if there are any aliases or functions fronting your nano; also you can run the nano exe using: $ command nano # runs exes in PATH and $ /usr/local/bin/nano # runs exe at path and see what version you get in each case. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Named pipes and multiple writers
On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote: BTW, I've been working on adding support for multiple readers. I expect to have a first cut ready within a week or two. Would you have any use for that? If so, I could revive the topic/fifo branch and push my patches there for you to test. Ken, what are the semantics for multiple readers? Do all readers see the same data, or is it first come first served or something else? -- = Norton Allen (he/him/his) Software Engineer Harvard University School of Engineering and Applied Sciences 12 Oxford St., Link Bldg. (Office 282) Cambridge, MA 02138 Phone: (617) 998-5553 = -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Named pipes and multiple writers
On 3/26/2020 10:06 AM, Ken Brown via Cygwin wrote: [Let's keep the discussion on the list in case others have suggestions.] On 3/25/2020 9:41 AM, sten.kristian.ivars...@gmail.com wrote: [snip] As far as I can see, reading through history, this have been a known issue for quite some time, but it seems like there have been some attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown) [snip] Does anyone have any knowledge about if this (topic/fifo branch) is working and/or if it is somehow planned to make it into the master branch and end up in a future release ? That branch is obsolete. Support for multiple writers was added to Cygwin as of release 3.1.0. Ok, thanks, but we're running 3.1.4 (and tested 3.1.5) but do still have problems (experiencing ENXIO (No such device or address)) but actually (as far as we see) with the 3:rd writer ? We need to investigate the issue more thoroughly and might get back when we have more knowledge Does the ENXIO come from fhandler_fifo::wait? If so, it's quite possible that there's a bug involving read_ready in my code. BTW, I've been working on adding support for multiple readers. I expect to have a first cut ready within a week or two. Would you have any use for that? If so, I could revive the topic/fifo branch and push my patches there for you to test. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Named pipes and multiple writers
[Let's keep the discussion on the list in case others have suggestions.] On 3/25/2020 9:41 AM, sten.kristian.ivars...@gmail.com wrote: [snip] As far as I can see, reading through history, this have been a known issue for quite some time, but it seems like there have been some attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown) [snip] Does anyone have any knowledge about if this (topic/fifo branch) is working and/or if it is somehow planned to make it into the master branch and end up in a future release ? That branch is obsolete. Support for multiple writers was added to Cygwin as of release 3.1.0. Ok, thanks, but we're running 3.1.4 (and tested 3.1.5) but do still have problems (experiencing ENXIO (No such device or address)) but actually (as far as we see) with the 3:rd writer ? We need to investigate the issue more thoroughly and might get back when we have more knowledge Does the ENXIO come from fhandler_fifo::wait? If so, it's quite possible that there's a bug involving read_ready in my code. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mingw pkg-config not working
Hello, I implemented the solution to this problem as a patch to pkgconf.cygport as requested. I attached small patch to this email, which resolved the troubles with CMake and Meson. I hope that you will find it useful and some developers will gently apply the correction to fix the issue. Thank you very much for your time and your support. Sincerely, Carlo Bramini. Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney ha scritto: > > On 20/02/2020 11:06, Carlo B. wrote: > [...] > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > example the one for i686 is: > > > > #!/bin/sh > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > But while this solution mostly works when you exec it from the command > > line, it makes impossible to detect the presence of the tool from > > meson and cmake build systems. > > If you try to do this on the bash prompt, you get: > > > > $ i686-w64-mingw32-pkg-config --version > > pkgconf: --version specified with other options or module names, > > assuming --modversion. > > Please specify at least one package name on the command line. > > > > and this is exactly what happens with those build systems (and perhaps > > others, I don't know): it tries to call pkg-config with "--version" > > and it executes the above script that calls pkgconf. But sadly, the > > presence of the "--personality" option makes the process to fail, > > because the "--version" is currently allowed only when no other > > options are added. > > And, for this reason, meson and cmake fail the detection of the tool. > > > > I have also filed an issue here for pkgconf: > > https://todo.sr.ht/~kaniini/pkgconf/10 > > because the solution is actually to ignore the presence of the > > "--personality" option when the "--version" is written, but > > unfortunately I have not received any feedback. > > > > So, I'm also writing here, with the hope that you could find a solution. > [...] > > Thanks for reporting this issue. > > I guess the alternative to fixing pkgconf would be to modify those > wrapper scripts to detect when the parameters are just '--version' (or > equivalent) and not use --personality in that case? > > These wrapper scripts are specific to cygwin (generated by the cygport, > see [1]) > > It's possible other distros have more sophisticated wrapper scripts, > which avoid this problem? > > If you do write or discover some improved wrapper scripts, a patch to > [1] to update them would be appreciated. > > [1] > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 pkgconf.cygport.patch Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
On Mar 26 10:00, Thomas Wolff wrote:
> A symbolic link created with WSL is neither interpreted in cygwin nor can it
> be deleted:
> > touch file
> > wsl ln -s file link
> > wsl ls -l link
> lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file
> > ls -l link
> -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
What kind of file are they in the real world? Reparse points? If so,
what content do they have? I attached a Q source from my vault
of old test apps to check on reparse point content. Please compile with
gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
It takes a single native NT path as parameter, kind of like this:
./rd-reparse '\??\C:\cygwin64\home\corinna\link'
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
#include
#include
#include
#include
typedef struct {
DWORD ReparseTag;
WORD ReparseDataLength;
WORD Reserved;
union {
struct {
WORD SubstituteNameOffset;
WORD SubstituteNameLength;
WORD PrintNameOffset;
WORD PrintNameLength;
DWORD Flag;
WCHAR PathBuffer[1];
} SymbolicLinkReparseBuffer;
struct {
WORD SubstituteNameOffset;
WORD SubstituteNameLength;
WORD PrintNameOffset;
WORD PrintNameLength;
WCHAR PathBuffer[1];
} MountPointReparseBuffer;
struct {
BYTE DataBuffer[1];
} GenericReparseBuffer;
};
} MY_REPARSE_DATA_BUFFER, *MY_PREPARSE_DATA_BUFFER;
//ULONG WINAPI RtlCreateUnicodeStringFromAsciiz (PUNICODE_STRING, PCSTR);
int
main (int argc, char **argv)
{
HANDLE fh;
char buf[MAXIMUM_REPARSE_DATA_BUFFER_SIZE];
DWORD siz;
MY_PREPARSE_DATA_BUFFER rp;
char *pbuf;
char name[32768];
NTSTATUS status;
IO_STATUS_BLOCK io;
UNICODE_STRING fname;
OBJECT_ATTRIBUTES attr;
RtlCreateUnicodeStringFromAsciiz (, argv[1]);
InitializeObjectAttributes(, , OBJ_CASE_INSENSITIVE, NULL, 0);
status = NtOpenFile (, FILE_READ_EA | FILE_READ_ATTRIBUTES | SYNCHRONIZE,
, ,
FILE_SHARE_VALID_FLAGS,
FILE_SYNCHRONOUS_IO_NONALERT
| FILE_OPEN_FOR_BACKUP_INTENT
| FILE_OPEN_REPARSE_POINT);
if (!NT_SUCCESS (status))
{
fprintf (stderr, "NtOpenFile: %08X\n", status);
return 1;
}
status = NtFsControlFile (fh, NULL, NULL, NULL, ,
FSCTL_GET_REPARSE_POINT, NULL, 0,
(LPVOID) buf, sizeof buf);
if (!NT_SUCCESS (status))
{
fprintf (stderr, "NtDeviceIoControlFile: %08lX\n", status);
CloseHandle (fh);
return 1;
}
rp = (MY_PREPARSE_DATA_BUFFER) buf;
printf ("ReparseTag: 0x%08x\n", rp->ReparseTag);
printf ("ReparseDataLength:%10d\n", rp->ReparseDataLength);
printf ("Reserved: %10d\n", rp->Reserved);
if (rp->ReparseTag == IO_REPARSE_TAG_SYMLINK
|| rp->ReparseTag == IO_REPARSE_TAG_SYMLINK)
{
printf ("SubstituteNameOffset: %10d\n",
rp->SymbolicLinkReparseBuffer.SubstituteNameOffset);
printf ("SubstituteNameLength: %10d\n",
rp->SymbolicLinkReparseBuffer.SubstituteNameLength);
printf ("PrintNameOffset: %10d\n",
rp->SymbolicLinkReparseBuffer.PrintNameOffset);
printf ("PrintNameLength: %10d\n",
rp->SymbolicLinkReparseBuffer.PrintNameLength);
if (rp->ReparseTag == IO_REPARSE_TAG_SYMLINK)
{
printf ("Flag: 0x%08x\n",
rp->SymbolicLinkReparseBuffer.Flag);
pbuf = (char *) rp->SymbolicLinkReparseBuffer.PathBuffer;
}
else
pbuf = (char *) rp->MountPointReparseBuffer.PathBuffer;
wcstombs (name,
(PWCHAR) (pbuf +
rp->SymbolicLinkReparseBuffer.SubstituteNameOffset),
rp->SymbolicLinkReparseBuffer.SubstituteNameLength / 2);
name[rp->SymbolicLinkReparseBuffer.SubstituteNameLength / 2] = '\0';
printf("SubstituteName: %s\n", name);
wcstombs (name,
(PWCHAR) (pbuf + rp->SymbolicLinkReparseBuffer.PrintNameOffset),
rp->SymbolicLinkReparseBuffer.PrintNameLength / 2);
name[rp->SymbolicLinkReparseBuffer.PrintNameLength / 2] = '\0';
printf("PrintName:%s\n", name);
}
else
{
WORD i;
for (i = 0; i < rp->ReparseDataLength; ++i)
{
printf ("%02x ", rp->GenericReparseBuffer.DataBuffer[i]);
if ((i + 1) % 16 == 0)
putchar ('\n');
}
}
CloseHandle (fh);
return 0;
}
signature.asc
Description: PGP signature
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
WSL symbolic links
A symbolic link created with WSL is neither interpreted in cygwin nor can it be deleted: > touch file > wsl ln -s file link > wsl ls -l link lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file > ls -l link -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > rm -f link /bin/rm: cannot remove 'link': Permission denied (even as admin) > cmd /c del link works. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
G++ creates unusable executable with -gdwarf-5 -Og, without any diagnostic issued
Relevant package versions (all the current latest):
* Cygwin: 3.1.4
* binutils: 2.43+1git.de9c1b7cfe-1
* gcc-core, gcc-g++, libgcc1, libstdc++6: 9.3.0-1
Sample program (foo.cc):
#include
using namespace std;
int
main(void)
{
cout << "OK" << endl;
return 0;
}
With a plain g++ foo.cc -o foo, I get a foo.exe that prints "OK".
However, with g++ -gdwarf-5 -Og foo.cc -o foo, I get a binary that reports
-bash: ./foo.exe: cannot execute binary file: Exec format error
when run.
GDB can load the binary and show symbols just fine, but trying to run results
in:
Error creating process /cygdrive/.../foo.exe, (error 193).
Using -gdwarf-4 instead of -gdwarf-5 or dropping -Og makes the problem go away.
It also seems to be c++-specific; a C version of the sample program resulted in
a working program
(could just be because a C++ program with iostream pulls in more, triggering
the issue).
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Putting packages up for adoption
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption. I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them. However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
>
> I am considering to take over python, and I am building 2.7.17 and 3.8.2
> to see how complicate it is.
>
> One question on the cygport
>
> # see PEP 394
> dosym python${slot}.exe /usr/bin/python
> dosym python${slot}.exe /usr/bin/python2
>
> do you see any problem to use alternatives for the same scope ?
The reason I avoided using alternatives for this was consistency.
Since we don't build our packages in a clean (ch)root, if a maintainer
had such created such symlinks themselves, and they were to be picked
up during a build (very likely), or simply relied upon by scripts which
typically hardcode a generic version (very common), it would lead to a
package which would not run identically, or possibly not at all, on
other users' systems. I would discourage using alternatives here.
Of course, in the meantime, the Python world has moved very strongly to
3.x, to the point that upstream has dropped it, Fedora has mostly
deprecated it, and /usr/bin/python is now a symlink to python3 provided
by a separate package. However wrt Python 2, the only version we care
about at this point is 2.7, and while it's lifespan is limited, it is
still needed.
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
Re: Problems using Qt5 and Apache Thrift
Hello Andrey Repin The sources and the documentation are her: https://thrift.apache.org/tutorial/cpp You must have libthrift installed. Maybe using threads is a better programming style, but i don't know, if it solves the problem. I use connecting and disconnecting to the service like braces around the rest of the application. At some points the application transfers data to the service and expects an answer. It is a synchronous communication and i use it like RPC (remote procedure call). The client sends a request and the service has to respond. Without the response the client cannot continue. Every client has its own service. Greetings Ramund Paulus > -Ursprüngliche Nachricht- > Von: Andrey Repin [mailto:anrdae...@yandex.ru] > Gesendet: Mittwoch, 25. März 2020 12:13 > An: PAULUS, Raimund, TI-ABN; cygwin@cygwin.com > Betreff: Re: Problems using Qt5 and Apache Thrift > > Greetings, PAULUS, Raimund, TI-ABN! > > > Problems using Qt5 and Apache Thrift > > ...snip... > > > Now i want to implement the interface parts with Qt 5. Here is the new > > program > sequence: > > > //-- > > program starts > > step 1: make the connection to the Linux server (Apache Thrift) > > step 2: initialize Qt interface (create widgets, buttons, ...) > > step 3: user interface (Qt) > > step 4: data transfer PC <-> Linux-Host (Apache Thrift) > > step 5: user interface (Qt) > > step 6: data transfer PC <-> Linux-Host (Apache Thrift) > > ... > > ... > > ... > > step n-1: end Qt app > > step n: close the connection to the host (Apache Thrift) > > program ends > > //-- > > > During step 2 the connection to the linux server is broken. You can see it > > with the netstat command. First error message arises in step 4: > > > "TSocket::write_partial() send() Broken pipe" > > I strongly suggest placing communication service in its own thread. > Then you could manage connection without having to worry about blocking > timeouts caused by GUI operations. > They will run asynchronously. > > > On a Linux box the client program runs perfectly. > > Only by coincidence, I suppose. > > > On the windows box the program works, if i initalize Qt before the > > connection to the server is made (step 2 before step 1). But that is not > > acceptable for me, because afterwards other widgets and buttons are created > > and i can not close and create the connection at each point. > > I suppose, the server dropping connection by timeout. But I'd urge you to > investigate this further. > > > For the tests I used the examples from the Apache Thrift Tutorial. > > Please include examples as text/plain attachments, if they are longer than a > few lines. > > > -- > With best regards, > Andrey Repin > Wednesday, March 25, 2020 14:08:25 > > Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problems using Qt5 and Apache Thrift
Supplement to my first email: the ascii-interface is created with libcurses. > -Ursprüngliche Nachricht- > Von: Andrey Repin [mailto:anrdae...@yandex.ru] > Gesendet: Mittwoch, 25. März 2020 12:13 > An: PAULUS, Raimund, TI-ABN; cygwin@cygwin.com > Betreff: Re: Problems using Qt5 and Apache Thrift > > Greetings, PAULUS, Raimund, TI-ABN! > > > Problems using Qt5 and Apache Thrift > > ...snip... > > > Now i want to implement the interface parts with Qt 5. Here is the new > > program > sequence: > > > //-- > > program starts > > step 1: make the connection to the Linux server (Apache Thrift) > > step 2: initialize Qt interface (create widgets, buttons, ...) > > step 3: user interface (Qt) > > step 4: data transfer PC <-> Linux-Host (Apache Thrift) > > step 5: user interface (Qt) > > step 6: data transfer PC <-> Linux-Host (Apache Thrift) > > ... > > ... > > ... > > step n-1: end Qt app > > step n: close the connection to the host (Apache Thrift) > > program ends > > //-- > > > During step 2 the connection to the linux server is broken. You can see it > > with the netstat command. First error message arises in step 4: > > > "TSocket::write_partial() send() Broken pipe" > > I strongly suggest placing communication service in its own thread. > Then you could manage connection without having to worry about blocking > timeouts caused by GUI operations. > They will run asynchronously. > > > On a Linux box the client program runs perfectly. > > Only by coincidence, I suppose. > > > On the windows box the program works, if i initalize Qt before the > > connection to the server is made (step 2 before step 1). But that is not > > acceptable for me, because afterwards other widgets and buttons are created > > and i can not close and create the connection at each point. > > I suppose, the server dropping connection by timeout. But I'd urge you to > investigate this further. > > > For the tests I used the examples from the Apache Thrift Tutorial. > > Please include examples as text/plain attachments, if they are longer than a > few lines. > > > -- > With best regards, > Andrey Repin > Wednesday, March 25, 2020 14:08:25 > > Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
