Re: mintty window border?
On 2023-08-25, Thomas Wolff via Cygwin wrote: > > > Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: > >On 2023-08-24, Backwoods BC via Cygwin wrote: > >>On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > >> wrote: > >>>This is an update to a question I had a couple of years ago > >>>https://cygwin.com/pipermail/cygwin/2021-April/248367.html > >>> > >>>Windows 11 now has an "accent color" option under > >>>Settings/Personalization/Colors that adds a thin (1px?) border around > >>>all windows, in a user-selectable color. This definitively eliminates > >>>the problem seen with overlapping mintty windows that have a dark grey > >>>or black background (where the shadow isn't visible). > >>> > >>>Just FYI > >>> > >>>-- > >>>Jim Garrison > >>>j...@acm.org > >>This is also true for Windows 10, although I may have had to > >>explicitly enable it (I don't remember). > >It's in the same place on Windows 10. I just enabled it. Thank you both! > But it adds the thin border only to the foreground window... > Thomas Yes, it's not as good as having a border around all windows all the time, or around just mintty and gvim windows, but it is so much better than nothing at all, or so it seems so far. Regards, Gary -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Thu, 24 Aug 2023 at 18:45, Martin Wege via Cygwin wrote:
>
> On Wed, Aug 23, 2023 at 1:06 AM Roland Mainz via Cygwin
> wrote:
> >
> > On Tue, Aug 22, 2023 at 4:52 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> > via Cygwin wrote:
> > > > FIFOs which don't make *any* sense
> > > > ... FWIW, a remote NFS fileystem.
> > >
> > > I got an impression that the OP is trying to deploy something (maybe the
> > > entire Cygwin) onto an
> > > NFS share. So the named FIFO "file" is also created in there.
> >
> > I agree with that impression. This is basically what large sites
> > (universities etc) do with UNIX and Linux: The machines mount an
> > user's ${HOMR} directory via automounter over NFS, and users are
> > discouraged (e.g. grumpy admin visiting you in person, blocking all
> > escape routes... =:-) ) from using the machine's local filesystems (in
> > Cygwin's case that includes "C:"!).
> >
> > In that case people want to use |mkfifo()|/|mkfifoat()| and/or
> > /usr/bin/mkfifo in their home directory, and don't expect that it does
> > not work.
> >
> > But that is what happens on Cygwin 3.4.8 right now, if someone tries
> > to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and
> > CITI NFSv4 clients):
> > |mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested
> >
> > Example (/cygdrive/h/ is my home directory shared from my Linux machine):
> > snip
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ uname -a
> > CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC
> > x86_64 Cygwin
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ 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)
> > H: on /cygdrive/h type nfs (binary,posix=0,user,noumount,auto)
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ls -l
> > total 1
> > -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> > cygwin_mkfifo_on_nfs.c
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ cat -n cygwin_mkfifo_on_nfs.c
> > 1 #include
> > 2 #include
> > 3 #include
> > 4 #include
> > 5 #include
> > 6 #include
> > 7
> > 8 int main(int ac, char *av[])
> > 9 {
> > 10 (void)puts("# start");
> > 11
> > 12 if
> > (mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) != 0)
> > 13 perror("mkfifo failed");
> > 14 (void)puts("# done.");
> > 15 return EXIT_SUCCESS;
> > 16 }
> > 17
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ gcc -g cygwin_mkfifo_on_nfs.c
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ./a
> > # start
> > # done.
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ls -l
> > total 68
> > -rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe
> > -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> > cygwin_mkfifo_on_nfs.c
> > lrwxrwxrwx 1 Unix_User+0 Unix_Group+011 Aug 23 00:12 myfifo.fifo
> > -> ':\0:c4:1000'
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ cat > -bash: myfifo.fifo: No such file or directory
> > snip
> >
> > Note that Cygwin does not interpret the file |myfifo.fifo| as FIFO,
> > instead it comes back as a symlink "myfifo.fifo -> ':\0:c4:1000'".
> >
> > AFAIK there are (at least) these two options to fix the problems:
> > 1. Check whether the filesystem for the fifos path is NFS
> > (cgywin.dll's |fs.fs_is_nfs()|), and if it is a symlink check if it
> > starts with ':\0:c4:' (assuming "c4" is the prefix for inodes created
> > with |mkfifo()|). If this condition is |true|, then cygwin |stat()|,
> > |open()| etc. should treat this inode as FIFO.
> > 2. Check whether the filesystem for the fifos path is NFS
> > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
> > |ENOSYS| (not implemented)
> >
> > Better algorithm for [1] might be to check whether the inode is a
> > symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
> > assuming this is more performant.
>
> We would like to see option 1 implemented,
+1
> maybe as an option in the
> CYGWIN environment variable
> (CYGWIN=nfs_emulate_dev_special_files_as_symlink ?)
+1
Ced
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
--
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: mintty window border?
Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: On 2023-08-24, Backwoods BC via Cygwin wrote: On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin wrote: This is an update to a question I had a couple of years ago https://cygwin.com/pipermail/cygwin/2021-April/248367.html Windows 11 now has an "accent color" option under Settings/Personalization/Colors that adds a thin (1px?) border around all windows, in a user-selectable color. This definitively eliminates the problem seen with overlapping mintty windows that have a dark grey or black background (where the shadow isn't visible). Just FYI -- Jim Garrison j...@acm.org This is also true for Windows 10, although I may have had to explicitly enable it (I don't remember). It's in the same place on Windows 10. I just enabled it. Thank you both! But it adds the thin border only to the foreground window... Thomas Regards, Gary -- 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: mintty window border?
On 2023-08-24, Backwoods BC via Cygwin wrote: > On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > wrote: > > > > This is an update to a question I had a couple of years ago > > https://cygwin.com/pipermail/cygwin/2021-April/248367.html > > > > Windows 11 now has an "accent color" option under > > Settings/Personalization/Colors that adds a thin (1px?) border around > > all windows, in a user-selectable color. This definitively eliminates > > the problem seen with overlapping mintty windows that have a dark grey > > or black background (where the shadow isn't visible). > > > > Just FYI > > > > -- > > Jim Garrison > > j...@acm.org > > This is also true for Windows 10, although I may have had to > explicitly enable it (I don't remember). It's in the same place on Windows 10. I just enabled it. Thank you both! Regards, Gary -- 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: mintty window border?
On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin wrote: > > This is an update to a question I had a couple of years ago > https://cygwin.com/pipermail/cygwin/2021-April/248367.html > > Windows 11 now has an "accent color" option under > Settings/Personalization/Colors that adds a thin (1px?) border around > all windows, in a user-selectable color. This definitively eliminates > the problem seen with overlapping mintty windows that have a dark grey > or black background (where the shadow isn't visible). > > Just FYI > > -- > Jim Garrison > j...@acm.org This is also true for Windows 10, although I may have had to explicitly enable it (I don't remember). -- 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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Hi Denis, Thanks for the report. More below... Denis Excoffier via Cygwin wrote: Hello, When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following error messages (see below). There seems to be a kind of loop in the hierarchy of #includes. Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove the 2 #includes from /usr/include/sys/cpuset.h, this is also ok. Regards, Denis Excoffier. In file included from /usr/include/sys/signal.h:23, from /usr/include/signal.h:6, from ./lib/signal.h:52, from /usr/include/time.h:158, from ./lib/time.h:47, from ./lib/sys/stat.h:44, from ./lib/fcntl.h:64, from ./lib/unistd.h:99, from ./lib/stdlib.h:98, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:69, from src/chroot.c:21: /usr/include/cygwin/signal.h:121:3: error: unknown type name 'pthread_attr_t' 121 | pthread_attr_t *sigev_notify_attributes; /* notification attributes */ | ^~ In file included from /usr/include/signal.h:6, from ./lib/signal.h:52, from /usr/include/time.h:158, from ./lib/time.h:47, from ./lib/sys/stat.h:44, from ./lib/fcntl.h:64, from ./lib/unistd.h:99, from ./lib/stdlib.h:98, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/#include types.h:39, from ./lib/stdio.h:69, from src/chroot.c:21: /usr/include/sys/signal.h:227:29: error: expected ')' before 'int' 227 | int pthread_kill (pthread_t, int); | ^~~~ | ) ISTM the above could be fixed by moving "#include " after all the typedefs in . That would be an odd location for an #include though. Another approach would be to have explicit external refs for the needed two functions in and remove the #includes there. In file included from /usr/include/sys/stat.h:22, from ./lib/sys/stat.h:47, from ./lib/fcntl.h:64, from ./lib/unistd.h:99, from ./lib/stdlib.h:98, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:69, from src/chroot.c:21: /usr/include/cygwin/stat.h:27:3: error: unknown type name 'timestruc_t' 27 | timestruc_t st_atim; | ^~~ /usr/include/cygwin/stat.h:28:3: error: unknown type name 'timestruc_t' 28 | timestruc_t st_mtim; | ^~~ /usr/include/cygwin/stat.h:29:3: error: unknown type name 'timestruc_t' 29 | timestruc_t st_ctim; | ^~~ /usr/include/cygwin/stat.h:32:3: error: unknown type name 'timestruc_t' 32 | timestruc_t st_birthtim; | ^~~ I don't have an answer for these. Awaiting more input from our wizards. I'm willing to submit the patch for any agreed solution. ..mark -- 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
xserver failing on new install - fatal error on xcb connection
I recently installed a fresh copy of cygwin64 on a new Windows 10 box. xserver starts but randomly fails after a few minutes with: waiting for X server to shut down winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. winMultiWindowXMsgProc - Fatal error 1 on xcb connection winDeinitMultiWindowWM - Noting shutdown in progress (II) Server terminated successfully (0). Closing log file. Any pointers for how to troubleshoot? -- 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: Test for Windows Administrator permissions from Cygwin terminal|script?
On Thu, Aug 24, 2023 at 8:52 AM Bill Stewart wrote:
On Thu, Aug 24, 2023 at 7:01 AM Andrew Schulman wrote:
>
> > How can I find out whether the current Cygwin terminal has
>> > Administrator rights? I want to safeguard our admin scripts with a
>> > simple test and bail out with an error if someone wants to do admin
>> > stuff (say: regtool) without admin privileges.
>>
>>
>> https://superuser.com/questions/660191/how-to-check-if-cygwin-mintty-bash-is-run-as-administrator/874615#874615
>>
>
> This answer may be misleading. For example, when I log on using an account
> that's a member of Administrators, my account is a member of the group, but
> the Administrators group token is not enabled. For example, if I log on as
> a member of the Administrators group and open a PowerShell window, I can
> run the following, and it will output the local Administrators group (there
> will be no output if the account is not a member of Administrators):
>
> PS C:\> whoami /groups /fo csv | ConvertFrom-Csv | Where-Object { $_.SID
> -eq "S-1-5-32-544" }
>
> That is, while it is true that the process is a member of the
> Administrators group, the group isn't enabled, so the process isn't
> actually running with administrative permissions. In Windows-speak we would
> say the process isn't "elevated" ("elevated" = "running with administrative
> permissions"). In other words, logging on as a member of Administrators
> doesn't mean that processes you start are elevated.
>
> IME, what is normally being asked for is whether the current process is
> elevated (i.e., the group is both present and enabled). The usual Windows
> API way to check this is the CheckTokenMembership() function:
>
>
> https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-checktokenmembership
>
> In that reference: "The CheckTokenMembership function simplifies the
> process of determining whether a SID is both present and enabled in an
> access token."
>
> As an example, I wrote a little Windows program called 'elevate' that has
> a '-t' option to test whether the current process is elevated:
>
> https://github.com/Bill-Stewart/elevate
>
To elaborate on the above, the cygwin 'id -G' command looks like it takes
this into account and only outputs enabled group IDs.
I should have checked this before I responded, of course.
In other words, 'id -G' outputs a 544 in its list if the current process is
elevated ("run as administrator"). The 544 won't be in there if the process
is not elevated. I just tested from an elevated PowerShell console:
PS C:\Windows\System32> ((id -G) -split ' ') -contains '544'
True
Sorry for any confusion.
Bill
--
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: mintty window border?
This is an update to a question I had a couple of years ago https://cygwin.com/pipermail/cygwin/2021-April/248367.html Windows 11 now has an "accent color" option under Settings/Personalization/Colors that adds a thin (1px?) border around all windows, in a user-selectable color. This definitively eliminates the problem seen with overlapping mintty windows that have a dark grey or black background (where the shadow isn't visible). Just FYI -- Jim Garrison j...@acm.org -- 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
can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Hello, When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following error messages (see below). There seems to be a kind of loop in the hierarchy of #includes. Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove the 2 #includes from /usr/include/sys/cpuset.h, this is also ok. Regards, Denis Excoffier. In file included from /usr/include/sys/signal.h:23, from /usr/include/signal.h:6, from ./lib/signal.h:52, from /usr/include/time.h:158, from ./lib/time.h:47, from ./lib/sys/stat.h:44, from ./lib/fcntl.h:64, from ./lib/unistd.h:99, from ./lib/stdlib.h:98, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:69, from src/chroot.c:21: /usr/include/cygwin/signal.h:121:3: error: unknown type name 'pthread_attr_t' 121 | pthread_attr_t *sigev_notify_attributes; /* notification attributes */ | ^~ In file included from /usr/include/signal.h:6, from ./lib/signal.h:52, from /usr/include/time.h:158, from ./lib/time.h:47, from ./lib/sys/stat.h:44, from ./lib/fcntl.h:64, from ./lib/unistd.h:99, from ./lib/stdlib.h:98, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:69, from src/chroot.c:21: /usr/include/sys/signal.h:227:29: error: expected ')' before 'int' 227 | int pthread_kill (pthread_t, int); | ^~~~ | ) In file included from /usr/include/sys/stat.h:22, from ./lib/sys/stat.h:47, from ./lib/fcntl.h:64, from ./lib/unistd.h:99, from ./lib/stdlib.h:98, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:69, from src/chroot.c:21: /usr/include/cygwin/stat.h:27:3: error: unknown type name 'timestruc_t' 27 | timestruc_t st_atim; | ^~~ /usr/include/cygwin/stat.h:28:3: error: unknown type name 'timestruc_t' 28 | timestruc_t st_mtim; | ^~~ /usr/include/cygwin/stat.h:29:3: error: unknown type name 'timestruc_t' 29 | timestruc_t st_ctim; | ^~~ /usr/include/cygwin/stat.h:32:3: error: unknown type name 'timestruc_t' 32 | timestruc_t st_birthtim; | ^~~ make[2]: *** [Makefile:11912: src/chroot.o] Error 1 make[1]: *** [Makefile:21297: all-recursive] Error 1 make: *** [Makefile:8434: all] Error 2 -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Wed, Aug 23, 2023 at 1:06 AM Roland Mainz via Cygwin
wrote:
>
> On Tue, Aug 22, 2023 at 4:52 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> via Cygwin wrote:
> > > FIFOs which don't make *any* sense
> > > ... FWIW, a remote NFS fileystem.
> >
> > I got an impression that the OP is trying to deploy something (maybe the
> > entire Cygwin) onto an
> > NFS share. So the named FIFO "file" is also created in there.
>
> I agree with that impression. This is basically what large sites
> (universities etc) do with UNIX and Linux: The machines mount an
> user's ${HOMR} directory via automounter over NFS, and users are
> discouraged (e.g. grumpy admin visiting you in person, blocking all
> escape routes... =:-) ) from using the machine's local filesystems (in
> Cygwin's case that includes "C:"!).
>
> In that case people want to use |mkfifo()|/|mkfifoat()| and/or
> /usr/bin/mkfifo in their home directory, and don't expect that it does
> not work.
>
> But that is what happens on Cygwin 3.4.8 right now, if someone tries
> to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and
> CITI NFSv4 clients):
> |mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested
>
> Example (/cygdrive/h/ is my home directory shared from my Linux machine):
> snip
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ uname -a
> CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC
> x86_64 Cygwin
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ 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)
> H: on /cygdrive/h type nfs (binary,posix=0,user,noumount,auto)
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ ls -l
> total 1
> -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58 cygwin_mkfifo_on_nfs.c
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ cat -n cygwin_mkfifo_on_nfs.c
> 1 #include
> 2 #include
> 3 #include
> 4 #include
> 5 #include
> 6 #include
> 7
> 8 int main(int ac, char *av[])
> 9 {
> 10 (void)puts("# start");
> 11
> 12 if
> (mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) != 0)
> 13 perror("mkfifo failed");
> 14 (void)puts("# done.");
> 15 return EXIT_SUCCESS;
> 16 }
> 17
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ gcc -g cygwin_mkfifo_on_nfs.c
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ ./a
> # start
> # done.
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ ls -l
> total 68
> -rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe
> -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> cygwin_mkfifo_on_nfs.c
> lrwxrwxrwx 1 Unix_User+0 Unix_Group+011 Aug 23 00:12 myfifo.fifo
> -> ':\0:c4:1000'
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ cat -bash: myfifo.fifo: No such file or directory
> snip
>
> Note that Cygwin does not interpret the file |myfifo.fifo| as FIFO,
> instead it comes back as a symlink "myfifo.fifo -> ':\0:c4:1000'".
>
> AFAIK there are (at least) these two options to fix the problems:
> 1. Check whether the filesystem for the fifos path is NFS
> (cgywin.dll's |fs.fs_is_nfs()|), and if it is a symlink check if it
> starts with ':\0:c4:' (assuming "c4" is the prefix for inodes created
> with |mkfifo()|). If this condition is |true|, then cygwin |stat()|,
> |open()| etc. should treat this inode as FIFO.
> 2. Check whether the filesystem for the fifos path is NFS
> (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
> |ENOSYS| (not implemented)
>
> Better algorithm for [1] might be to check whether the inode is a
> symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
> assuming this is more performant.
We would like to see option 1 implemented, maybe as an option in the
CYGWIN environment variable
(CYGWIN=nfs_emulate_dev_special_files_as_symlink ?)
Thanks,
Martin
--
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: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Wed, Aug 23, 2023 at 5:44 PM Jeffrey Altman via Cygwin wrote: > > On 8/22/2023 10:52 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin > wrote: > >> FIFOs which don't make *any* sense > >> ... FWIW, a remote NFS fileystem. > > I got an impression that the OP is trying to deploy something (maybe the > > entire Cygwin) onto an NFS share. So the named FIFO "file" is also created > > in there. > > > > It's pointless to assume that the FIFO can be used as a communication > > device between the hosts that can mount the share, but it can be quite > > feasible to envision a scenario, in which the same host opens the FIFO > > located on the share from two processes and establish the communication > > using that special "file" (which is basically a special data-less i-node). > > I've been following this thread with quite a bit of curiosity. For those > who do not know me, I'm the lead developer of the AFS filesystem on > Windows. There have been requests for more than two decades for AFS > clients to add support for locally created pipe files because AFS > volumes are often used as home directories (even on Windows) and so many > applications allocate a pipe in the home directory as a method of > inter-process communication or a lock. The problem is that even if the > intended usage of the file is entirely local, the directory object, the > directory entry and the allocated inode (or equivalent) is network > visible. Who cares? It is up to the user, script or application author to do 'the right thing(tm)'. > > What happens when the user executes two copies of an > application such as PyCharm on two separate machines sharing the same > home directory? Does the directory entry and inode get reused on startup > and/or deleted on exit? How does that impact the process instance on the > other machine? The conclusion I came to long ago is that if pipes are to > be implemented in a network file system namespace then the pipes must be > fully functional network pipes. In just about all cases applications can > be configured to use a non-default paths. In my opinion they should not > be placed in a shared file system. Oh my god. Please have this debate at the Austin Group. They do the POSIX standard. We're here about implementing the POSIX standard. We only want that mkfifo() works with Cygwin on a NFS filesystem, as specified in https://pubs.opengroup.org/onlinepubs/009696799/functions/mkfifo.html My intention was not to invent something new. Just code using mkfifo, and scripts using /usr/bin/mkfifo, should work on NFS. On UNIX this works. Have a look at https://cygwin.com/pipermail/cygwin/2023-August/254266.html, sounds like there is a feasible way to implement this. Thanks, Martin -- 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: Cygwin pathconf() query filesystem kernel data? Re: How does Cygwin detect MSFT NFSv3 file system? Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...
On Tue, Aug 22, 2023 at 12:07 AM Brian Inglis wrote: > > On 2023-08-21 06:03, Martin Wege via Cygwin wrote: > > On Sat, Aug 19, 2023 at 7:50 PM Brian Inglis wrote: > >> > >> On 2023-08-18 07:09, Martin Wege via Cygwin wrote: > >>> On Fri, Aug 18, 2023 at 10:44 AM Corinna Vinschen via Cygwin > >>> wrote: > > On Aug 17 20:49, Martin Wege via Cygwin wrote: > > On Mon, Aug 14, 2023 at 10:56 PM Corinna Vinschen via Cygwin > > wrote: > >> and the result is the same. Note that Cygwin supports MSFT NFSv3 but > >> not CITI NFSv4.1 internally. No gurantee that Cygwin always does what > >> is necessary for that other NFS. > > > > 1. How does Cygwin detect whether something is a MSFT NFSv3, or not? > > Cygwin /bin/mount lists the CITI NFSv4.1 as 'nfs', so there *IS* > > something which detects that? > > The filesystem name returned by NtQueryVolumeInformationFile is "NFS". > If any other NFS returns the same filesystem name, it will be treated > just like MSFT NFSv3. > > > 2. Are Cygwin soft link handing depend on MSFT NFSv3 or not, i.e. does > > the Cygwin soft link code behave differently for MSFT NFSv3 file > > systems? > > Yes. NFS doesn't support symlink creation and symlink reading via > the usual functions, because Windows symlinks are created as reparse > points. NFS doesn't support reparse points. So the developers of > the MSFT NFS client had to invent their own way to create and > read NFS symlinks: > > https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;hb=HEAD#l1719 > > https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;hb=HEAD#l2750 > > > 3. Does Cygwin implement the pathconf() api? > > Yes. Surprisingly, you can check this yourself by just calling the > function and trying to compile your code. > >>> > >>> Apologies, how do we say in German? "Ich sollte meine Frage > >>> konkretisieren:" > >>> > >>> Does the Cygwin implementation of pathconf() support query data of the > >>> underlying filesystem based on data from the kernel, as UNIX does? So > >>> pathconf() returns different values for NTFS, ReFS, or Windows builtin > >>> NFSv3? > >>> > >>> I am asking, because as far as I know the Linux implementation is not > >>> a syscall, and instead glibc guesses values based on builtin static > >>> data, and whatever fstatfs() has to offer. Compared to that UNIX > >>> (Solaris, AIX, HPUX, ...) have pathconf() as a syscall, and actually > >>> ask the filesystem itself. > >> > >> Many library functions are implemented as documented either in the Cygwin > >> packages cygwin-doc and man-pages-posix available for installation; and > >> use as > >> e.g. `man 3p fpathconf`, also available online at: > >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html > >> or > >> https://man7.org/linux/man-pages/man3/fpathconf.3p.html > >> and for comparison and reference we make Cygwin package man-pages-linux > >> available for installation; and use as e.g. `man -m linux 3 fpathconf`, > >> also > >> available online at: > >> > >> https://man7.org/linux/man-pages/man3/fpathconf.3.html > >> > >> suggestions for setup are in the package announcements made every 9-12 > >> weeks > >> when the latest Linux man-pages package is released and updated on Cygwin. > >> > >> Please also note that the getconf(1) program is installed as part of > >> Cygwin and > >> can access f/pathconf variables associated with a pathname argument, as > >> shown in > >> getconf(1) `man 1 getconf` and getconf(1p) `man 1p getconf`. > > > > Thanks, but my question was about the Cygwin *implementation*: Does it > > distinguish between NTFS, REFS, FAT, NFS? Does it use data obtained > > from the Windows kernel at runtime, or does it rely on static data > > compiled into the cygwin.dll library? > > My suggestion was to encourage you to try out the command on the relevant > filesystems, or feel free to check out the repo and the implementation. Where in the git is the implementation of pathconf()? Thanks, Martin -- 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: Test for Windows Administrator permissions from Cygwin terminal|script?
On Sat, Aug 19, 2023 at 10:15 AM ASSI via Cygwin wrote: > > Martin Wege via Cygwin writes: > > How can I find out whether the current Cygwin terminal has > > Administrator rights? I want to safeguard our admin scripts with a > > simple test and bail out with an error if someone wants to do admin > > stuff (say: regtool) without admin privileges. > > Windows really doesn't have a defined notion of what is or is not an > "administrator". Each particular definition will be insufficient or > invalid in certain contexts. When you're dealing with hardened > installations (via group policies or otherwise), large windows domains > and/or server administration you may have to be way more specific than > just looking at one simple indication. > > That said, most commonly the presence of SID S-1-5-32-544 in your user > token (in Cygwin: gid=544, unless you override it in the group config) > will be the best simple approximation. Incidentally, this is what tcsh > is using on Cygwin to define the "superuser" for the purpose of setting > the prompt with "%#": > https://github.com/tcsh-org/tcsh/blob/d075ab5b4155ebff9d30e765733c030c3da5e362/tc.prompt.c#L212 > > For (ba)sh scripts you can parse the output from id along the lines of > > id -G | grep -q '\<544\>' && echo admin || echo "not admin" Is there any guarantee that the UNIX GID of the "administrator" will always be "544", regardless of locale or Country-specific version of Windows? Also, this might be something for a Cygwin ADMINISTRATOR FAQ, if there is such a thing. Thanks, Martin -- 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: EXTERNAL SENDER: Re: Cygwin openssh AllowGroups
Thanks for the suggestion. I discovered that AllowUsers and AllowGroups are applied via logical AND, not logical OR, as I expected. Thanks, Corinna! Best Regards, Dale Lobb From: Cygwin On Behalf Of Corinna Vinschen via Cygwin Sent: Friday, August 18, 2023 3:49 AM To: cygwin@cygwin.com Cc: Corinna Vinschen Subject: EXTERNAL SENDER: Re: Cygwin openssh AllowGroups On Aug 17 21: 11, Dale Lobb via Cygwin wrote: > Is there a known issue in Cygwin's implementation of openssh in the > AllowGroups clause of sshd_config? I cannot get it to work. It should work, just as AllowUsers. Maybe you should run On Aug 17 21:11, Dale Lobb via Cygwin wrote: > Is there a known issue in Cygwin's implementation of openssh in the > AllowGroups clause of sshd_config? I cannot get it to work. It should work, just as AllowUsers. Maybe you should run clinet and/or server with debugging on, to see what it does. Corinna -- Problem reports: https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!PI4dZuVR!kacZAQE52eG-WMSOkCq99tpXUA56p01VYAFyv6ZstJ3cXUAZsYi3dIumSsfV-ZxJdYxJu4XHMcC0UKqI$ FAQ: https://urldefense.com/v3/__https://cygwin.com/faq/__;!!PI4dZuVR!kacZAQE52eG-WMSOkCq99tpXUA56p01VYAFyv6ZstJ3cXUAZsYi3dIumSsfV-ZxJdYxJu4XHMSRqqFfY$ Documentation: https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!PI4dZuVR!kacZAQE52eG-WMSOkCq99tpXUA56p01VYAFyv6ZstJ3cXUAZsYi3dIumSsfV-ZxJdYxJu4XHMfocdziT$ Unsubscribe info: https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-simple__;Iw!!PI4dZuVR!kacZAQE52eG-WMSOkCq99tpXUA56p01VYAFyv6ZstJ3cXUAZsYi3dIumSsfV-ZxJdYxJu4XHMWJpcTVm$ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipients and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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: Test for Windows Administrator permissions from Cygwin terminal|script?
On Thu, Aug 24, 2023 at 7:01 AM Andrew Schulman wrote:
> How can I find out whether the current Cygwin terminal has
> > Administrator rights? I want to safeguard our admin scripts with a
> > simple test and bail out with an error if someone wants to do admin
> > stuff (say: regtool) without admin privileges.
>
>
> https://superuser.com/questions/660191/how-to-check-if-cygwin-mintty-bash-is-run-as-administrator/874615#874615
>
This answer may be misleading. For example, when I log on using an account
that's a member of Administrators, my account is a member of the group, but
the Administrators group token is not enabled. For example, if I log on as
a member of the Administrators group and open a PowerShell window, I can
run the following, and it will output the local Administrators group (there
will be no output if the account is not a member of Administrators):
PS C:\> whoami /groups /fo csv | ConvertFrom-Csv | Where-Object { $_.SID
-eq "S-1-5-32-544" }
That is, while it is true that the process is a member of the
Administrators group, the group isn't enabled, so the process isn't
actually running with administrative permissions. In Windows-speak we would
say the process isn't "elevated" ("elevated" = "running with administrative
permissions"). In other words, logging on as a member of Administrators
doesn't mean that processes you start are elevated.
IME, what is normally being asked for is whether the current process is
elevated (i.e., the group is both present and enabled). The usual Windows
API way to check this is the CheckTokenMembership() function:
https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-checktokenmembership
In that reference: "The CheckTokenMembership function simplifies the
process of determining whether a SID is both present and enabled in an
access token."
As an example, I wrote a little Windows program called 'elevate' that has a
'-t' option to test whether the current process is elevated:
https://github.com/Bill-Stewart/elevate
Hope this helps clarify.
Bill
--
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: Test for Windows Administrator permissions from Cygwin terminal|script?
> Hello, > > How can I find out whether the current Cygwin terminal has > Administrator rights? I want to safeguard our admin scripts with a > simple test and bail out with an error if someone wants to do admin > stuff (say: regtool) without admin privileges. https://superuser.com/questions/660191/how-to-check-if-cygwin-mintty-bash-is-run-as-administrator/874615#874615 -- 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: scp stalls on uploading in cygwin 3.5 current master.
On Aug 24 12:31, Takashi Yano via Cygwin wrote:
> On Thu, 24 Aug 2023 06:05:02 +0900
> Takashi Yano wrote:
> > Hi Corinna,
> >
> > After the commit dedbbd74d0a8, "scp file server:." stalls.
> > I confirmed this when the "server" is a Linux machine.
> > The problem does not occur if it is reverted.
> >
> > Could you please have a look?
> >
> > commit dedbbd74d0a8f3b7dfae6188321703a47bb8a2b3
> > Author: Corinna Vinschen
> > Date: Tue Aug 1 14:22:55 2023 +0200
> >
> > Cygwin: select: workaround FD_WRITE network event handling
> >
> > The FD_WRITE event is a false friend. It indicates ready to write
> > even if the next send fails with WSAEWOULDBLOCK. *After* the fact,
> > FD_WRITE will be cleared until sending is again possible, but that
> > is too late for a select/write loop.
> >
> > Workaround that by using the WinSock select function when peeking
> > at a socket and FD_WRITE gets indicated. WinSock select fortunately
> > indicates writability correctly.
> >
> > Fixes: 70e476d27be8 ("(peek_socket): Use event handling for peeking
> > socket.")
> > Signed-off-by: Corinna Vinschen
>
> I'm not sure why at all, however, the following patch seems to
> solve the issue.
>
> diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
> index 7b9473849..de5794c9f 100644
> --- a/winsup/cygwin/select.cc
> +++ b/winsup/cygwin/select.cc
> @@ -1790,7 +1790,7 @@ peek_socket (select_record *me, bool)
>if (events & FD_WRITE)
> {
> wfd_set w = { 1, { fh->get_socket () } };
> - TIMEVAL t = { 0 };
> + TIMEVAL t = { .tv_sec = 0, .tv_usec = 1 };
>
> if (_win32_select (0, NULL, , NULL, ) == 0)
> events &= ~FD_WRITE;
Yeah, this is weird. A TIMEVAL value of 0 indicates non-blocking,
so why should waiting a usec make that better? It also potentially
slows down Cygwin's select noticably if multiple sockets are part
of the descriptor set.
Hmmm.
Is it possible that _win32_select returns with SOCKET_ERROR for
some reason?
Unfortunately I'm a bit swamped ATM, but rather than setting t to 1
usec, what if the check goes:
if (_win32_select (0, NULL, , NULL, ) != 1)
?
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
Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH
ASSI via Cygwin-apps wrote:
Christian Franke via Cygwin-apps writes:
If binutils, gzip and tar also would support this, the patch would be
empty :-)
GZip has -n though ...
For gzip I decided to keep the timestamp and use (the GNU version of)
touch instead.
and GNU tar --mtime and --clamp-mtime, so why not use
that?
Already done:
+ if [ -n "${SOURCE_DATE_EPOCH}" ]
+ then
+ # Ensure reproducible sort order and last modification times <=
SOURCE_DATE_EPOCH
+ TAR_SOURCE_DATE_OPTS="--sort=name --mtime=@${SOURCE_DATE_EPOCH}
--clamp-mtime"
+ fi
:-)
--
Regards,
Christian
Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH
Christian Franke via Cygwin-apps writes: > If binutils, gzip and tar also would support this, the patch would be > empty :-) GZip has -n though and GNU tar --mtime and --clamp-mtime, so why not use that? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH
Brian Inglis via Cygwin-apps wrote: On 2023-08-23 11:39, Christian Franke via Cygwin-apps wrote: A small step towards reproducible packaging... Currently only tested with upcoming smartmontools package - contains only exe, man, doc files (no dll, lib, ...). Multiple cygport runs produce binary identical distribution tarballs if SOURCE_DATE_EPOCH (from the past) is specified in the cygport file. What format is this variable? Unix epoch, see: https://reproducible-builds.org/docs/source-date-epoch/ Some tools like gcc and gropdf already support this: $ echo '__DATE__ __TIME__' | SOURCE_DATE_EPOCH=1672531200 gcc -E -xc - # 0 "" # 0 "" # 0 "" # 1 "" "Jan 1 2023" "00:00:00" $ TZ=UTC SOURCE_DATE_EPOCH=1672531200 man -Tpdf ls | TZ=UTC pdfinfo - Creator: groff version 1.23.0 Producer: gropdf version 1.23.0 CreationDate: Sun Jan 1 00:00:00 2023 UTC ModDate: Sun Jan 1 00:00:00 2023 UTC ... If binutils, gzip and tar also would support this, the patch would be empty :-) Would be best to use some ISO format e.g. %Y-%m-%dT%H:%M:%SZ or %Y-%m-%dT%H:%M:%S [local] that is human readable and can be used by all POSIX command options [e.g. see touch(1p) -d] that accept date-time stamps. I use this in smartmontools.cygport: SOURCE_DATE=2023-08-23 SOURCE_DATE_EPOCH=$(date -d "$SOURCE_DATE UTC" +%s) This relies on GNU date, BSD date is very different, a POSIX-only date would be useless in this context. Could do with docs and NEWS entries for new variables, otherwise packagers do not know it exists, and how to use it e.g. #f* Information/BUILD_REQUIRES # SYNOPSIS ... Of course this should be documented, but I left this for a later patch. -- Regards, Christian
