Re: Window 10 authorization problems
On 01/21/2018 03:28 AM, Achim Gratz wrote: Robert McBroom writes: Troubles through several cygwin releases with getting the files to have the right permissions when running startwinx from an initial cygwin64 terminal. Messages follow: Is that a network share? Data drive D:\cygwin64\ A directory listing gives: -- 2 mukx mukx 0 Jan 18 18:44 .serverauth.7284-c On Window 7 these files are properly read,write for the user. As Brian said, please check the DACL on your home directory via icacls. The above shows that Cygwin thinks there are _no_ ACL attached and it seems it can't create them either, so I suspect your home is on one of those shares that disallow both the reading and writing of DACL. You could try to use it by mounting it with the "noacl" option, but that will create other problems down the road, so you might need to move your home directory (as far as Cygwin is concerned) someplace else. This might be as easy as using a subdirectory in your current home or it might require using a different share. Regards, Achim. Both Windows 10 home and the insider edition of Windows 10 Pro are installed and share the data drive. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Window 10 authorization problems
On 01/20/2018 08:39 PM, Brian Inglis wrote: On 2018-01-20 16:35, Robert McBroom wrote: Troubles through several cygwin releases with getting the files to have the right permissions when running startwinx from an initial cygwin64 terminal. Messages follow: xauth:� /home/mukx/.serverauth.7284 not writable, changes will be ignored xauth:� /home/mukx/.Xauthority not writable, changes will be ignored xauth:� timeout in locking authority file /home/mukx/.Xauthority winInitMultiWindowWM - DISPLAY=:0.0 winMultiWindowXMsgProc - DISPLAY=:0.0 winMultiWindowXMsgProc - Could not open display, try: 1, sleeping: 5 winInitMultiWindowWM - Could not open display, try: 1, sleeping: 5 waiting for X server to begin accepting connections . winMultiWindowXMsgProc - Could not open display, try: 2, sleeping: 5 winInitMultiWindowWM - Could not open display, try: 2, sleeping: 5 and so on until the system gives up. A directory listing gives: � --� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .serverauth.7284-c � --� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .serverauth.7284-l � --� 1 mukx��������� mukx����������� 54 Jan 18 18:44 .Xauthority � --� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .Xauthority-c � --� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .Xauthority-l On Window 7 these files are properly read,write for the user. Normally a problem with no default ACls (DACLs) on the directory; use getfacl and icacls to view, and setfacl to set up permissions like: # file: /home/$USER # owner: SYSTEM # group: SYSTEM user::rwx user:$USER:rwx group::--- group:Administrators:rwx mask:rwx other:--- default:user::rwx default:user:$USER:rwx default:group::--- default:group:Administrators:rwx default:mask:rwx default:other:--- C:/Users/$USER NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) $HOST\$USER:(OI)(CI)(F) Thanks Brian.� Made some progress. $ getfacl /home/$USER # file: /home/mukx # owner: mukx # group: mukx user::rwx group::rwx other:rwx default:user::--- default:group::--- default:other:rwx The default DACL's look strange with other enabled.� Looked at the root $ getfacl / # file: / # owner: Administrators # group: Administrators user::rwx group::rwx other:rwx default:user::--- default:group::--- default:other:rwx Used setacl $ getfacl /home/mukx # file: /home/mukx # owner: mukx # group: mukx user::rwx group::rwx other:rwx default:user::rwx default:group::rwx default:other:rwx startxwin will now run when the initial cygwin64 terminal is started with "run as administrator" but not otherwise from the same windows user who is the system administrator. �-rw---� 1 mukx mukx����������� 54 Jan 21 13:37 .serverauth.5628 �-rw---� 1 mukx��������� mukx���������� 286 Jan 21 13:37 .Xauthority �-rw---� 1 mukx��������� mukx���������� 764 Jan 21 13:38 .xsession-errors -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Ejecting a USB drive using Cygwin (sync)?
On 2018-01-23 16:36, Steven Penny wrote:
> On Tue, 23 Jan 2018 14:13:24, Brian Inglis wrote:
>> I found the following utility works well without elevation - Windows code
>> from
>> http://www.leapsecond.com/tools/eject.{c,exe}:
>>
>> // eject -- Allow safe removal of USB thumb drive.
>> // - Command line tool to flush/dismount/eject USB drive.
>> // - Simpler than mouse clicking through taskbar "Safely Remove Hardware"
>> icon.
>> // - Usable in batch file scripts.
>> // 02-Nov-2012 Tom Van Baak (tvb) www.LeapSecond.com/tools
>> ...
>> // Per MSDN, follow procedure for safe removal of USB drive.
>> int drive_eject (char *drive)
>> {
>> HANDLE hDev;
>> // Convert vintage DOS drive letter to weird Windows object pathname.
>> char path[10];
>> sprintf(path, ".\\%s", drive);
>> // Open (with write, but no lock) to flush pending writes.
>> DEV_OPEN(path, GENERIC_READ | GENERIC_WRITE);
>> FlushFileBuffers(hDev);
>> CloseHandle(hDev);
>> // Open (with read, and lock) to dismount and eject.
>> DEV_OPEN(path, GENERIC_READ);
>> DEV_IOCTL(FSCTL_LOCK_VOLUME);
>> DEV_IOCTL(FSCTL_DISMOUNT_VOLUME);
>> DEV_IOCTL(IOCTL_STORAGE_EJECT_MEDIA);
>> DEV_IOCTL(FSCTL_UNLOCK_VOLUME);
>> CloseHandle(hDev);
>> return 0;
>> }
>
> No, this is not the code from that site. The code is similar, but I see you
> have
> at least removed some empty lines. If you are going to do so, you need to
> clearly present said changes to the community - something like "adapted from
> http://..."; or "modified from http://...";, etc.
>
> Software copyright - even open source license is serious, and you should give
> it
> due respect.
I was providing information, that's why I said /from/, gave the link to the
original, and included the copyright, which does not include a link to the MSDN
article it mentions: checking any licences are left as an exercise for any
reader who wants to make use of the program or code other than for their own
private use.
What do you mean by "/even/ open source licence"?!
You sound like the early Bill Gates ;^>
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
On 1/24/2018 7:16 PM, Yaakov Selkowitz wrote:
On 2018-01-24 13:25, Ken Brown wrote:
On 1/20/2018 6:49 PM, Ken Brown wrote:
On 1/20/2018 7:23 AM, Ken Brown wrote:
On 1/19/2018 10:27 PM, Ken Brown wrote:
Here's another issue that's come up with _FORTIFY_SOURCE. One of the
emacs source files, fileio.c, makes use of a pointer to readlinkat.
When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to
`__ssp_protected_readlinkat'" linking error. Does this sound like
something that will be fixed with the new gcc release?
I got to this sooner than expected:
$ cat ssp_test.c
#define _FORTIFY_SOURCE 1
#include
void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t));
void baz ()
{
foo (readlinkat);
}
The following patch seems to fix the problem:
-#define __ssp_inline extern __inline__ __attribute__((__always_inline__,
__gnu_inline__))
+#define __ssp_inline extern __inline__ __attribute__((__always_inline__))
No, that would have other consequences:
https://gcc.gnu.org/onlinedocs/gcc/Inline.html
I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which
Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__.
The BSDs also stuck with GCC 4.2 due to licensing reasons, so you can't
always compare.
Yaakov, is there a reason that Cygwin needs __gnu_inline__?
Because the semantics of inline changed in GCC 4.3.
It apparently prevents fortified functions from being used as function pointers.
I am currently testing the following, which seems to match glibc in this
detail:
--- a/newlib/libc/include/ssp/ssp.h
+++ b/newlib/libc/include/ssp/ssp.h
@@ -51,7 +51,6 @@
__chk_fail()
#define __ssp_decl(rtype, fun, args) \
rtype __ssp_real_(fun) args __asm__(__ASMNAME(#fun)); \
-__ssp_inline rtype fun args __asm__(__ASMNAME("__ssp_protected_" #fun)); \
__ssp_inline rtype fun args
#define __ssp_redirect_raw(rtype, fun, args, call, cond, bos) \
__ssp_decl(rtype, fun, args) \
Works for me.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
On 2018-01-24 13:25, Ken Brown wrote:
> On 1/20/2018 6:49 PM, Ken Brown wrote:
>> On 1/20/2018 7:23 AM, Ken Brown wrote:
>>> On 1/19/2018 10:27 PM, Ken Brown wrote:
Here's another issue that's come up with _FORTIFY_SOURCE. One of the
emacs source files, fileio.c, makes use of a pointer to readlinkat.
When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to
`__ssp_protected_readlinkat'" linking error. Does this sound like
something that will be fixed with the new gcc release?
>>>
>>> I got to this sooner than expected:
>>>
>>> $ cat ssp_test.c
>>> #define _FORTIFY_SOURCE 1
>>> #include
>>> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t));
>>>
>>> void baz ()
>>> {
>>> foo (readlinkat);
>>> }
>
> The following patch seems to fix the problem:
>
> -#define __ssp_inline extern __inline__ __attribute__((__always_inline__,
> __gnu_inline__))
> +#define __ssp_inline extern __inline__ __attribute__((__always_inline__))
No, that would have other consequences:
https://gcc.gnu.org/onlinedocs/gcc/Inline.html
> I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which
> Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__.
The BSDs also stuck with GCC 4.2 due to licensing reasons, so you can't
always compare.
> Yaakov, is there a reason that Cygwin needs __gnu_inline__?
Because the semantics of inline changed in GCC 4.3.
> It apparently prevents fortified functions from being used as function
> pointers.
I am currently testing the following, which seems to match glibc in this
detail:
--- a/newlib/libc/include/ssp/ssp.h
+++ b/newlib/libc/include/ssp/ssp.h
@@ -51,7 +51,6 @@
__chk_fail()
#define __ssp_decl(rtype, fun, args) \
rtype __ssp_real_(fun) args __asm__(__ASMNAME(#fun)); \
-__ssp_inline rtype fun args __asm__(__ASMNAME("__ssp_protected_" #fun)); \
__ssp_inline rtype fun args
#define __ssp_redirect_raw(rtype, fun, args, call, cond, bos) \
__ssp_decl(rtype, fun, args) \
--
Yaakov
signature.asc
Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
On 1/20/2018 6:49 PM, Ken Brown wrote:
> On 1/20/2018 7:23 AM, Ken Brown wrote:
>> On 1/19/2018 10:27 PM, Ken Brown wrote:
>>> On 1/18/2018 6:28 PM, Ken Brown wrote:
On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote:
> On 2018-01-18 08:35, Ken Brown wrote:
>> On 1/17/2018 5:29 PM, Ken Brown wrote:
>>> Do we need a new gcc release to go along with the recent ssp
>>> changes?
>>
>> The following commit message seems to answer my question:
>>
>> Note that this does require building gcc with
>> --disable-libssp and
>> gcc_cv_libc_provides_ssp=yes.
>
> Correct.
>
>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new
>> gcc release? In the meantime, I guess package maintainers have to
>> build
>> with -U_FORTIFY_SOURCE in order to test building with Cygwin
>> 2.10.0. Or
>> am I missing something?
>
> -D_FORTIFY_SOURCE is not the default, so simply omitting it is
> sufficient.
I was talking about building projects in which _FORTIFY_SOURCE is
defined by default. That happens, for instance, in the gnulib
subdirectory of the emacs tree, so it may affect other projects that
use gnulib also.
> You could also just delete
> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it
> anymore and it wasn't even being used properly in the first place.
That's a simpler workaround than what I was doing. Thanks.
>>>
>>> Here's another issue that's come up with _FORTIFY_SOURCE. One of the
>>> emacs source files, fileio.c, makes use of a pointer to readlinkat.
>>> [More precisely, the file uses an external function foo() with a
>>> parameter 'bar' that's a pointer to a function; foo is called in
>>> fileio.c with bar = readlinkat.]
>>>
>>> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to
>>> `__ssp_protected_readlinkat'" linking error. Does this sound like
>>> something that will be fixed with the new gcc release?
>>>
>>> I realize I haven't given you full details, but it might be a few
>>> days until I have a chance to extract an STC for this issue, so I
>>> thought I'd give it a shot.
>>>
>>> If you can't answer the question based on the information above, I'll
>>> make an STC as soon as I can.
>>
>> I got to this sooner than expected:
>>
>> $ cat ssp_test.c
>> #define _FORTIFY_SOURCE 1
>> #include
>> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t));
>>
>> void baz ()
>> {
>> foo (readlinkat);
>> }
>>
>> $ gcc -c -O1 ssp_test.c
>>
>> $ objdump -x ssp_test.o | grep readlinkat
>> 6 .rdata$.refptr.__ssp_protected_readlinkat 0010
>> 0180 2**4
>> [...]
The following patch seems to fix the problem:
--- ssp.h~ 2018-01-22 09:18:18.0 -0500
+++ ssp.h 2018-01-24 13:44:55.856635800 -0500
@@ -41,7 +41,7 @@
#endif
#define __ssp_real(fun)__ssp_real_(fun)
-#define __ssp_inline extern __inline__ __attribute__((__always_inline__,
__gnu_inline__))
+#define __ssp_inline extern __inline__ __attribute__((__always_inline__))
#define __ssp_bos(ptr) __builtin_object_size(ptr, __SSP_FORTIFY_LEVEL > 1)
#define __ssp_bos0(ptr) __builtin_object_size(ptr, 0)
I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which
Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__.
Yaakov, is there a reason that Cygwin needs __gnu_inline__? It apparently
prevents fortified functions from being used as function pointers.
Using my test case again, here's what happens with and without __gnu_inline__:
With:
$ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat
6 .rdata$.refptr.__ssp_protected_readlinkat 0010
0180 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA,
LINK_ONCE_DISCARD (COMDAT .refptr.__ssp_protected_readlinkat 18)
[ 4](sec 7)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x
.rdata$.refptr.__ssp_protected_readlinkat
[ 18](sec 7)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
.refptr.__ssp_protected_readlinkat
[ 19](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
__ssp_protected_readlinkat
0007 R_X86_64_PC32 __ssp_protected_readlinkat
RELOCATION RECORDS FOR [.rdata$.refptr.__ssp_protected_readlinkat]:
R_X86_64_64 __ssp_protected_readlinkat
Without:
$ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat
[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x
__ssp_protected_readlinkat
[ 27](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x readlinkat
0005 R_X86_64_PC32 readlinkat
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xhost: unable to open display ""
Hi- The solution was stupider than I thought: 1. I thought my DISPLAY was set, but it actually wasn’t. It worked with “:0.0”. 2. “ssh -Y” worked, whereas “ssh -X” did not. Voila! (so far) Thanks for your help, guys. Jim Waltz Sent from my iPhone On Jan 23, 2018, at 22:48, Jack mailto:ostrof...@users.sourceforge.net>> wrote: On 2018.01.23 19:57, Mark Geisert wrote: Waltz, James wrote: Hi- I think that I have installed all the necessary packages, but I still get the above error, when I type “xhost +” on my local machine. I am also still getting a “cannot open display: localhost:10.0” error. This is DESPITE the fact that: - I set DISPLAY to “localhost:10.0” - X11Forwarding is set to “yes” in the sshd_config file - I changed the “hosts” file, under /etc to have actual IP addresses. Any idea why this might be happening? Yes. Change that "10" to "0". So it's "localhost:0.0" or even ":0.0". Should work much better :) Unless ssh is involved, which was not stated, but I suspect might be part of the issue. Jack -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem running bittwiste
On 1/23/2018 10:37 PM, oscar gomez wrote: Hi , my name is Oscar and i want to use bitt wiste but when i run command in cmd show me the next problem: C:\Users\oscar\Desktop\MPLS ECUADOR>bittwiste -H 0 [main] bittwiste 424 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com bittwiste: input file not specified C:\Users\oscar\Desktop\MPLS ECUADOR> This error is addressed by FAQ 4.46 on the Cygwin web site: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings Basically the software you're running is bundled with a very old version of Cygwin. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
