Re: Repairing permissions after windows reinstall
Greetings, Henry S. Thompson! > Andrey Repin writes: >> Greetings, Henry S. Thompson! >> >>> Good news: My cygwin file tree survived a Windows (10) reinstall >>> Not-so-good news: I have a new SID, so not only do I not own those files >>> any more (that's easily fixed), but I don't have the permissions I >>> should, because they are now held by some miscellaneous old SID. >> >> So, what? Go to top directory properties, Advanced, Owner tab, Change, and >> change the owner to what is desired. > Much to glib an answer. Changing the owner is the _last_ thing you want > to do after (programmatically) changing a bunch of ACLs. Much like in POSIX, ACL and ownership are not directly dependent one on another in Windows. I don't understand your statement. -- With best regards, Andrey Repin Monday, July 4, 2016 06:25:58 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
64 bit Cywgin 2.5.2 on Wine: python fails with sem_init: Invalid argument
Hi folks,
When compiling 64 bit Cygwin on Wine, I found a python{2,3} failure
when building documentation [1]:
xmlto --skip-validation --with-dblatex pdf -o cygwin-ug-net/ -m
/drone/src/github.com/cygwin/cygwin/winsup/doc/fo.xsl
/drone/src/github.com/cygwin/cygwin/winsup/doc/cygwin-ug-net.xml
sem_init: Invalid argument
Traceback (most recent call last):
File "/usr/bin/dblatex", line 10, in
from dbtexmf.dblatex import dblatex
File "/usr/lib/python2.7/site-packages/dbtexmf/dblatex/dblatex.py",
line 8, in
from dbtexmf.core.dbtex import DbTex, DbTexCommand
File "/usr/lib/python2.7/site-packages/dbtexmf/core/dbtex.py", line
11, in
import urllib
File "/usr/lib/python2.7/urllib.py", line 26, in
import socket
File "/usr/lib/python2.7/socket.py", line 67, in
from _ssl import SSLError as sslerror
ImportError: cannot import name SSLError
make[3]: [Makefile:104: cygwin-ug-net/cygwin-ug-net.pdf] Error 1 (ignored)
According to my previous experience this happens with previous version
of Cygwin 64 bit on Wine, but works fine on Windows, and works fine on
32 bit Cygwin on Wine. I can't test latest git HEAD Cygwin version due
to another known failure.
I tried to track down the problem, and I found during the call of
sem_init(sem, pshared=0, value=1), in some case pshared and value were
unexpectedly changed to large integers after
verifyable_object_isvalid().
I tried to reproduce with a simplified test case, and got the below
code which behaviors wrong but not exactly in the same way:
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
sem_t *p_sem = malloc(sizeof(sem_t));
memset(p_sem, 0xcc, sizeof(sem_t)); /* trigger exception handling
code in Cygwin sem_init()-->verifyable_object_isvalid() */
sem_init(p_sem, 0, 1);
return 0;
}
Compiled using Cygwin gcc -pthread, The above code works fine on
Cygwin on Windows and 32 bit Cygwin on Wine, but causes a stack
overflow on 64 bit Cygwin on Wine. Unfortunately it does not fail
exatly in the same way to Cygiwn python, but at least it brings some
interesting question.
I think it is a Wine bug which does not handle exception correctly,
and I'm trying to track down deeper. At the time could anyone provide
some hint which piece of Cygwin code could I learn to write a pure
Win32 test case emulating the above example?
I also attached +seh log comparing 64 bit Cygwin and 32 bit Cygwin on
Wine, which show the stackoverflow on 64 bit but handles fine on 32
bit, hopefully that helps. I created a Wine bug on [2].
Thank you!
[1] https://tea-ci.org/cygwin/cygwin/4
[2] https://bugs.wine-staging.com/show_bug.cgi?id=691
--
Regards,
Qian Hong
-
http://www.winehq.org
00ec:trace:seh:raise_exception code=c005 flags=0 addr=0x180154e5e
ip=180154e5e tid=00ec
00ec:trace:seh:raise_exception rax= rbx=000600010590
rcx=000600010590 rdx=df0df04c
00ec:trace:seh:raise_exception rsi=0001 rdi=
rbp=cc10 rsp=cb10
00ec:trace:seh:raise_exception r8= r9=
r10=cb40 r11=000100401130
00ec:trace:seh:raise_exception r12=1000 r13=7b47ead0
r14=7f7e8000 r15=7fffc3f8
00ec:trace:seh:RtlVirtualUnwind type 1 rip 180154e5e rsp cb10
00ec:trace:seh:dump_unwind_info func 114dc0-114eaa
00ec:trace:seh:dump_unwind_info unwind info at 0x1802cd50c flags 1 prolog 0x4
bytes function 0x180154dc0-0x180154eaa
00ec:trace:seh:dump_unwind_info 0x4: subq $0x58,%rsp
00ec:trace:seh:dump_unwind_info handler 0x180071c30 data at 0x1802cd518
00ec:trace:seh:call_handler calling handler 0x180071c30 (rec=0xc9e0,
frame=0xcb10 context=0xbab0, dispatch=0xb980)
00ec:Call
ntdll.RtlUnwindEx(cb10,180154e91,c9e0,,bab0,b9d0)
ret=180071c5f
00ec:trace:seh:RtlUnwindEx code=c005 flags=2 end_frame=0xcb10
target_ip=0x180154e91 rip=7bc9d3ba
00ec:trace:seh:RtlUnwindEx rax=0033fe80 rbx=0033fe80
rcx=bab0 rdx=
00ec:trace:seh:RtlUnwindEx rsi=bab0 rdi=b250
rbp=bab0 rsp=b0b0
00ec:trace:seh:RtlUnwindEx r8=c9e0 r9=
r10=777bafe0 r11=775856f0
00ec:trace:seh:RtlUnwindEx r12=b250 r13=c9e0
r14=000180154e91 r15=b980
00ec:err:seh:setup_exception stack overflow 7472 bytes in thread 00ec eip
7bc99c63 esp 88d0 stack 0xffe0-0xa000-0x1
00ec:warn:seh:abort_thread exit frame outside of stack limits in thread 00ec
frame 0x33ff80 stack 0xa000-0x1
00ca:trace:seh:raise_exception code=c005 flags=0 addr=0x61124db9
ip=61124db9 tid=00ca
00ca:trace:seh:raise_exception info[0]=
00ca:trace:seh:raise_exception info[1]=ccd0
00ca:trace:seh:raise_exception eax= ebx=20010348 ecx=
edx=
Re: cygstart.exe can't open file:///C:/
Even if it's similar to Windows command-line, you are still in a POSIX system, and Cygwin use /cygdrive/ for all the drive letters. So for file:///C:/ you should use file:///cygdrive/c/ On 2016-07-04 at 01:51, Gene Pavlovsky wrote: > cygstart‘s manpage says it’s similar to the Windows command-line start > command. > It is indeed able to open http://example.com in the default browser. > However, cygstart file:///C:/ results in an error message: > Unable to start 'C:\cygwin\c\': The specified file was not found. > The Windows start command opens file:///C:/ links in the default > browser without a hitch. > > -- > 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 > -- Juan Miguel Navarro Martínez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -- 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
cygstart.exe can't open file:///C:/
cygstart‘s manpage says it’s similar to the Windows command-line start command. It is indeed able to open http://example.com in the default browser. However, cygstart file:///C:/ results in an error message: Unable to start 'C:\cygwin\c\': The specified file was not found. The Windows start command opens file:///C:/ links in the default browser without a hitch. -- 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: Anecdotal: Rebase and Visual Studio 2015 and /etc
On 7/1/2016 7:38 PM, Warren Young wrote: On Jul 1, 2016, at 4:40 PM, Warren Young wrote: I’ve written a script to do that automatically. I’ve improved the script so that it no longer requires any parameters. It finds the last-used setup.ini file and extracts the list of currently-installed packages, all on its own. This script has a couple of problems. First, it doesn't take dependency loops into account. For example, if package p requires q and q requires p, then both will be marked as non-root. Second, if the mirror was used for both an x86 and x86_64 installation, it always uses the x86 setup.ini, regardless of the current architecture. 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: symlinks to unlinked but open files should work
Am 03.07.2016, 13:14 Uhr, schrieb Corinna Vinschen:
You don't even need a symlink. This will show the same result:
exec >out1
rm out1
[[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
I noticed that too meanwhile, but I thought you would not need that
information ;)
It's only about the /dev/fd-symlinks, otherwise cygwin seems to be
correct: they don't work anywhere on an open but deleted file:
ln -sf out1 lout1
exec >out1
[[ -w lout1 ]] || echo lout1 not writable-1 1>&2
rm out1
[[ -w lout1 ]] || echo lout1 not writable-2 1>&2
rm lout1
correctly prints the second message.
In Cygwin we move a deleted but still open file out of the way (into
the trash) so the path is incorrect afterwards but even if we wouldn't
do that, the underlying problem can't be solved:
The problem is that a deleted file in Windows can't be opened anymore.
If you translate the above -w into a libc call access
("/dev/fd/1", W_OK) or its Windows equivalent, that call will always
fail on a deleted file. Same for open/CreateFile, etc.
Sorry, but off the top of my head I don't see a feasible workaround for
this problem.
Not a big issue - I don't know any situation this would break except the
above /dev/fd-test.
-Helmut
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] [Updated/New] Perl distributions
The following Perl distributions have been updated to their latest version available from CPAN: perl-CPAN-Reporter-1.2018 perl-Cpanel-JSON-XS-3.0217-1 perl-IO-Socket-SSL-2.029 perl-List-AllUtils-0.11 perl-Mojolicious-6.66-1 perl-Parse-CPAN-Meta-1.4421-1 perl-Term-ReadLine-Gnu-1.34-1 perl-Test-Simple-1.302035-1 perl-Text-BibTeX-0.74-1 perl-XML-LibXML-2.0126-1 The following Perl distributions are new in Cygwin as dependencies for other packages: perl-List-UtilsBy-0.10 Please note that "pure" Perl distributions are now available from noarch to avoid the duplication that had existed between the x86 and x86_64 architecture branches. -- *** 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: 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: symlinks to unlinked but open files should work
On Jul 1 22:40, Helmut Karlowski wrote:
> Cygwin seems to look up a symlink wrong:
>
> When the target-file is unlinked while it is used by a process the file
> still exists and the symlink should point to that file.
>
> Test:
>
> ln -s out1 lout1
> exec >lout1
> rm out1
> [[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
> rm lout1
>
> Only on cygwin it prints the message.
You don't even need a symlink. This will show the same result:
exec >out1
rm out1
[[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
In Cygwin we move a deleted but still open file out of the way (into
the trash) so the path is incorrect afterwards but even if we wouldn't
do that, the underlying problem can't be solved:
The problem is that a deleted file in Windows can't be opened anymore.
If you translate the above -w into a libc call access
("/dev/fd/1", W_OK) or its Windows equivalent, that call will always
fail on a deleted file. Same for open/CreateFile, etc.
Sorry, but off the top of my head I don't see a feasible workaround for
this problem.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
