I've been trying to build OpenJDK for several weeks now and have never
been able to get to the end of the build because of random failures.
Last night I had a hunch to turn off one of the cores in BIOS and after
doing that the problems have gone away. My system is a Lenovo T500,
Model 2081-CTO, w
Terrence Brannon wrote:
> Subject:
> [Bug 429] term.h on Cygwin not existent. no warning during configure
> From:
> bugzilla-dae...@gollem.science.uva.nl
term.h is provided by ncurses, and is located in /usr/include/ncurses/.
So, all you need to do (I think) is add -I/usr/include/ncurses to your
Just FYI.
--- Begin Message ---
http://gollem.science.uva.nl/bugzilla/show_bug.cgi?id=429
Jan Wielemaker changed:
What|Removed |Added
Status|NEW
On Nov 16 10:33, aputerguy wrote:
>
> Corinna Vinschen writes:
> > In that case, the problem probably occurs because userB has no
> > permissions to read the file permissions. Cygwin's chmod creates a
> > POSIX compatible ACL, which adds READ_CONTROL permissions for everyone.
>
> That seems to b
Corinna Vinschen writes:
> In that case, the problem probably occurs because userB has no
> permissions to read the file permissions. Cygwin's chmod creates a
> POSIX compatible ACL, which adds READ_CONTROL permissions for everyone.
That seems to be the case here and would seem to explain it - t
Christopher Faylor wrote:
> On Mon, Nov 16, 2009 at 09:14:11AM +, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>> On Nov 16 09:01, Dave Korn wrote:
aputerguy wrote:
> So is 'subinacl' just another example of these badly behaved non-Cygwin
> applications?
Looks like it.
On Mon, Nov 16, 2009 at 09:14:11AM +, Dave Korn wrote:
>Corinna Vinschen wrote:
>> On Nov 16 09:01, Dave Korn wrote:
>>> aputerguy wrote:
>>>
So is 'subinacl' just another example of these badly behaved non-Cygwin
applications?
>>> Looks like it.
>>>
If so, is there anything on
On Mon, Nov 16, 2009 at 03:55:43PM +0100, Thomas Wolff wrote:
>Thomas Wolff wrote:
>> Corinna Vinschen wrote:
>>> ...
>>> Or, just for kicks, try to create a file "abc:def:ghi" under 1.5 or,
>>> FWIW, under CMD.
>> Well, I wanted to withdraw my arguments when I read this but then I
>> simply tried
On Sun, Nov 15, 2009 at 06:59:03PM -0800, aputerguy wrote:
>
>Dave Korn writes...
>> So, it just doesn't work, and that's using all MS software; it's not
>> going
>> to work any better in bash. I think you're probably out of luck here; I
>> don't
>> know any way to capture direct console output l
Thomas Wolff wrote:
Corinna Vinschen wrote:
...
Or, just for kicks, try to create a file "abc:def:ghi" under 1.5 or,
FWIW, under CMD.
Well, I wanted to withdraw my arguments when I read this but then I
simply tried in 1.5 and it worked quite well...
Where I visually mistook the second ":" for
Corinna Vinschen wrote:
On Nov 16 13:32, Andy Koppe wrote:
2009/11/16 Thomas Wolff:
But with it being supported, "foo:bar" *is* a POSIX filename and can quite
transparently be handled like a file
If you create a file called "foo:bar" in Cygwin 1.5, a directory
listing will actua
On Nov 16 13:32, Andy Koppe wrote:
> 2009/11/16 Thomas Wolff:
> > But with it being supported, "foo:bar" *is* a POSIX filename and can quite
> > transparently be handled like a file
>
> If you create a file called "foo:bar" in Cygwin 1.5, a directory
> listing will actually show a file called "foo
On Nov 16 04:41, aputerguy wrote:
>
> Corinna Vinschen writes:
> > It means it doesn't know the SIDs. They don't show up in /etc/passwd
> > and /etc/group.
>
> BUT THEY DO! And they must since why else would doing a trivial 'chmod'
> (that doesn't change anything) all of a sudden make them show
2009/11/16 aputerguy:
> Well I'm using Putty to ssh into my Windows machine running cygwin 1.5
> When I do tab completion on the "foo:bar" file it completes to
> foo\357\200\272 but perhaps the Unicode is coming from the Putty terminal
> (which is set to UTF-8) though somehow bash is preserving the
2009/11/16 Thomas Wolff:
I'd suspect the support for ADSs in 1.5 was rather accidental anyway.
POSIX programs certainly don't know about them, and you get the rather
weird situation that "files" like foo:bar can be accessed but don't
show up in the directory they're in. Hence I
Corinna Vinschen writes:
> It means it doesn't know the SIDs. They don't show up in /etc/passwd
> and /etc/group.
BUT THEY DO! And they must since why else would doing a trivial 'chmod'
(that doesn't change anything) all of a sudden make them show up.
$ subinacl /noverbose /nostatistic /file
C:
Corinna Vinschen wrote:
On Nov 16 12:56, Thomas Wolff wrote:
Andy Koppe wrote:
I'd suspect the support for ADSs in 1.5 was rather accidental anyway.
POSIX programs certainly don't know about them, and you get the rather
weird situation that "files" like foo:bar can be accessed but don't
On Nov 16 04:19, aputerguy wrote:
>
> I think it should still at least be documented as a change especially since a
> deliberate change.
It was never documented that streams are supported at all. And the usage
of special DOS chars for filenames is documented:
http://cygwin.com/1.7/cygwin-ug-net
I think it should still at least be documented as a change especially since a
deliberate change.
--
View this message in context:
http://old.nabble.com/Seems-like-treatment-of-NTFS-ADS-%28foo%3Abar%29-changed-between-1.5-and-1.7-but-not-mentioned-in-What%27s-Changed-tp26363833p26370924.html
Sent
On Nov 16 12:56, Thomas Wolff wrote:
> Andy Koppe wrote:
> >I'd suspect the support for ADSs in 1.5 was rather accidental anyway.
> >POSIX programs certainly don't know about them, and you get the rather
> >weird situation that "files" like foo:bar can be accessed but don't
> >show up in the direct
Andy Koppe wrote:
I'd suspect the support for ADSs in 1.5 was rather accidental anyway.
POSIX programs certainly don't know about them, and you get the rather
weird situation that "files" like foo:bar can be accessed but don't
show up in the directory they're in. Hence I think the right way to
ac
Corinna Vinschen wrote:
> On Nov 16 09:01, Dave Korn wrote:
>> aputerguy wrote:
>>
>>> So is 'subinacl' just another example of these badly behaved non-Cygwin
>>> applications?
>> Looks like it.
>>
>>> If so, is there anything one can do other than to use one of the other
>>> methods to get a pro
I've updated the Cygwin 1.7 version of whois to 4.7.36-1.
Whois is a client for the whois directory service.
It allows you to retrieve information on domains name,
IP addresses, and more.
If you're not sure what version do you have you can
use the following command to both check version number
an
On Nov 16 09:01, Dave Korn wrote:
> aputerguy wrote:
>
> > So is 'subinacl' just another example of these badly behaved non-Cygwin
> > applications?
>
> Looks like it.
>
> > If so, is there anything one can do other than to use one of the other
> > methods to get a properly authenticated ssh l
On Nov 15 10:18, Steven Monai wrote:
> In 1.7.0-64, /usr/sbin/cygserver is linked against cygstdc++-6.dll.
> cygserver will not run (exit status 128) unless the 'libstdc++6' package
> is installed.
Fixed in CVS.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding
aputerguy wrote:
> So is 'subinacl' just another example of these badly behaved non-Cygwin
> applications?
Looks like it.
> If so, is there anything one can do other than to use one of the other
> methods to get a properly authenticated ssh login?
You mean, apart from the other methods to g
On Nov 15 20:02, aputerguy wrote:
>
> OK - I just re-read the ntsec portion of the cygwin manual and found this
> paragraph:
>
> [...]
>
> So is 'subinacl' just another example of these badly behaved non-Cygwin
> applications?
> If so, is there anything one can do other than to use one of the oth
On Nov 15 08:48, aputerguy wrote:
>
> Jason DePriest wrote:
> > Does 'ls -n' show the UIDs under both users?
>
> ls -n shows uid=gid=4294967295 which I believe is UINT_MAX (2^32-1), so this
> is just -1.
>
> Maybe what's happening is that cygwin is returning an error (-1) here?
It means it does
28 matches
Mail list logo