Ken Brown cornell.edu> writes:
> Check setup.log.full. If that doesn't help, try running the script
> manually to see what happens (most likely a fork failure requiring a
> full rebase).
Well, if it's really a fresh install, the full rebase just has happened, so
if there's still a fork problem
Jon TURNEY wrote
> On 14/01/2016 16:02, Tim Chick wrote:
>> Jon TURNEY wrote
>
> I built a 32-bit version as well, but there was a slight delay with that
> getting moved into the release. It should be mirroring out now, though.
Hi Jon,
I've just tried the 7.10.1-1 package, and it works fine fo
On 20/01/2016 19:32, KARL BOTTS wrote:
In less.exe, when I use either the G or F commands on a largish CRLF file, it
responds:
How largish ?
On Cygwin 32 bit and W7-64 I see no problem with 224 Mbytes
Cannot seek to that file position (press RETURN)
in the bottom "command editing line
On 21/01/2016 06:34, Miya Miller wrote:
$ 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)
D: on /cygdrive/d type ntfs (binary,posi
On 1/20/2016 9:20 PM, Richard Heintze wrote:
On 1/19/2016 6:34 PM, Richard Heintze wrote:
Regarding my choice of terms: I was trying use terms consistent with that old
link
"https://cygwin.com/ml/cygwin/2011-02/msg00416.html";.
That message doesn't even mention emacs. That's why I said in m
Hi Corinna,
The truth is out! :-)
@@ 'cygpath -S -u' (2.4.0, 32-bits) informs us that the system directory
is:
/drv/c/Windows/SysWOW64
However, it probably not what we want here.
(hint: do_sysfolders() in utils/cygpath.cc)
Regards,
Henri
-
@@ uname -a
CYGWIN_NT-6.1-WOW Seven 2.3.1
Houder xs4all.nl> writes:
> %% uname -a
> CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin
>
> %% /usr/bin/cygpath -S -u
> /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want
> it here?
> %% /usr/bin/cygpath -S -w
> C:\Windows\system32
> %%
> %% /usr/bin
On 2016-01-21 16:11, Achim Gratz wrote:
Houder xs4all.nl> writes:
%% uname -a
CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin
%% /usr/bin/cygpath -S -u
/drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we
want
it here?
%% /usr/bin/cygpath -S -w
C:\Windows
On Jan 21 15:11, Achim Gratz wrote:
> Houder xs4all.nl> writes:
> > %% uname -a
> > CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin
> >
> > %% /usr/bin/cygpath -S -u
> > /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we want
> > it here?
> > %% /usr/bin/cy
I am finding a large performance gap between plain "ls" and "ls -F" in a
directory with many files on a network share (NetApp disguised as NTFS if
that matters). This has been there for quite a while, I've just now
realized what the reason was (I have "ls -F" as an alias for "ls" in my
interactive
On Thu, Jan 21, 2016 at 10:44 AM, Achim Gratz wrote:
> I am finding a large performance gap between plain "ls" and "ls -F" in a
> directory with many files on a network share (NetApp disguised as NTFS if
> that matters). This has been there for quite a while, I've just now
> realized what the rea
William M. (Mike) Miller gmail.com> writes:
> The overhead appears to be in checking for executable files; using
> --file-type instead of -F, which just omits the '*' category, reduces
> the time for ls in one of my (local) large directories from over one
> second to 0.04 seconds.
Indeed. Thanks
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Stephen John Smoogen
> Sent: Wednesday, January 20, 2016 4:19 PM
> To: cygwin@cygwin.com
> Subject: Re: New cygwin install hanging on postinstall
>
> On 20 January 2016 at 17:06, KARR, DAVI
On 2015-12-10 16:20, Ken Brown wrote:
I think libgtk3-devel should require libepoxy-devel:
$ grep epoxy /usr/lib/pkgconfig/gtk+-3.0.pc
Requires.private: atk atk-bridge-2.0 epoxy >= 1.0 pangoft2
gio-unix-2.0 >= 2.45.8
Thanks; hopefully the GNOME deps are fixed now.
--
Yaakov
--
Problem repo
On 2016-01-21 16:42, Corinna Vinschen wrote:
On Jan 21 15:11, Achim Gratz wrote:
Houder xs4all.nl> writes:
> %% uname -a
> CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin
>
> %% /usr/bin/cygpath -S -u
> /drv/c/Windows/SysWOW64 < Nice, the truth is out! ... but do we wa
On Jan 21 19:34, Houder wrote:
> On 2016-01-21 16:42, Corinna Vinschen wrote:
> >On Jan 21 15:11, Achim Gratz wrote:
> >>Houder xs4all.nl> writes:
> >>> %% uname -a
> >>> CYGWIN_NT-6.1-WOW Seven 2.4.0(0.293/5/3) 2016-01-15 16:14 i686 Cygwin
> >>>
> >>> %% /usr/bin/cygpath -S -u
> >>> /drv/c/Window
Hi Achim,
I'm also having this issue but my investigation has found it to be a behavior
specific to C-DOT. This doesn't happen with 7mode. I currently have a support
case open with NetApp to get to the bottom of this behavior. It could be a
Cygwin bug.
> -Original Message-
> From: cy
:16 x86_64 Cygwin
64-%% cygpath -S
/drv/c/Windows/System32
64-%%
64-%% ./cygpath-64-2.4.0-snapshot -S
/drv/c/Windows/System32
64-%% ./cygpath-64-2.4.0-snapshot -S -U
/proc/cygdrive/c/Windows/System32
Btw, files in both cygwin-inst-20160121.tar.xz appear to be "included"
multiple times (3 or
In my particular case, we're seeing this behavior:
7-mode: (//devnas04/largedisk/bsmith/netapp)
:$ //devnas04/largedisk/bsmith/netapp>time ls -ld struct5*
-rw-r--r-- 1 bsmith Domain Users 0 Nov 5 10:25 struct51.log
[snipped]
-rw-r--r-- 1 bsmith Domain Users 0 Nov 5 10:26 struct5z.prf
real0
Henri writes:
> Yes, your proposal will work ... BECAUSE in that specific case, redirection
> will be switched OFF (hey, study the URL that I posted).
Yes, I've read that. What goes still unanswered is if that's the only
place Windows ever looks for those files. I guess yes, but I can't find
no
Corinna Vinschen writes:
> Yes, that was necessary to return case-correct paths. I commited a
> patch and hour and a half ago and uploaded a new snapshot to
> https://cygwin.com/snapshots/ Please give it a try.
For base-files I still plan to do
cygpath -U $( cygpath -Sw )
dance so it will wor
On 1/21/2016 3:02 AM, Achim Gratz wrote:
Ken Brown cornell.edu> writes:
Check setup.log.full. If that doesn't help, try running the script
manually to see what happens (most likely a fork failure requiring a
full rebase).
Well, if it's really a fresh install, the full rebase just has happene
On 1/21/2016 12:40 PM, KARR, DAVID wrote:
-Original Message-
On 20 January 2016 at 17:06, KARR, DAVID wrote:
I was installing cygwin for the first time on a Win7-32bit box.
It is hanging in postinstall, with "0/Perpetual" and
"/etc/postinstall/0p_texlive_prep.dash. I've tried this twi
Bill Smith writes:
> Hi Achim,
> I'm also having this issue but my investigation has found it to be a
> behavior specific to C-DOT. This doesn't happen with 7mode. I
> currently have a support case open with NetApp to get to the bottom of
> this behavior. It could be a Cygwin bug.
Hmm. I have
KARR, DAVID writes:
> While it's sitting here, I dumped out "/var/log/setup.log.full". Here is the
> end of the file:
>
> The following DLLs couldn't be rebased because they were in use:
> /usr/bin/cygssp-0.dll
> /usr/bin/cygperl5_22.dll
> /usr/bin/cyggcc_s-1.dll
> /usr/b
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Achim Gratz
> Sent: Thursday, January 21, 2016 12:10 PM
> To: cygwin@cygwin.com
> Subject: Re: New cygwin install hanging on postinstall
>
> KARR, DAVID writes:
> > While it's sitting here,
On 2016-01-21 20:44, Houder wrote:
Btw, files in both cygwin-inst-20160121.tar.xz appear to be "included"
multiple times (3 or more) -- just saying.
Please, ignore the above (my 7-zip exe must be in error).
Regards,
Henri
--
Problem reports: http://cygwin.com/problem
Created a new directory in my home directory with the following: mkdir test
created an empty file in this directory with: touch test/empty
When I list the contents of this path I get the following:
$ ls -Al test
total 0
--w-rw+ 1 kdstah GROUP_CHANGED 0 Jan 21 16:35 empty
My umask is set to 00
On 21/01/16 21:17, KARR, DAVID wrote:
-Original Message-
From: cygwin-owner cygwin.com [mailto:cygwin-owner cygwin.com] On
Behalf Of Achim Gratz
Sent: Thursday, January 21, 2016 12:10 PM
To: cygwin cygwin.com
Subject: Re: New cygwin install hanging on postinstall
KARR, DAVID writes:
Thanks you all for the replies.
Achim writes:
> What goes still unanswered is if that's the only
> place Windows ever looks for those files. I guess yes, but I can't find
> no positive confirmation.
Sorry not sure what you mean. Henri's link shows file system redirection does
not apply to %windi
Until recently, I've been able to build gcc under cygwin just fine. But
(relatively) recent checkins (232454 & 232071) are causing problems.
I've been trying to track down what to do about them, but crawling thru
the depths of makefiles, sed scripts, etc is proving difficult for this
long-tim
David Lee gmail.com> writes:
> Sorry not sure what you mean.
What I mean is this: are all the Windows versions that Cygwin supports
looking for the hosts and other files in
%windir%\system32\drivers\etc
or are there some versions, situations or configurations where it looks for
those files i
Bill Smith progress.com> writes:
> The difference is 1.3 seconds versus 1 minute 7 seconds. The directory is
identical on the two NetApps and
> they both contain ~29K files. C-dot (Cluster Data On Tap) is the newest
operating system for the NetApp. It
> also supports the newer SMB protocols.
>
Greetings, KARR, DAVID!
>> > I was installing cygwin for the first time on a Win7-32bit box.
> It has 4g RAM. Checking "Resource Monitor" while the install is running,
> there is 750MB "available".
How much memory is "available" is not an indication for a 32-bit OS. You
simply can not allocate
Greetings, Achim Gratz!
>> Sorry not sure what you mean.
> What I mean is this: are all the Windows versions that Cygwin supports
> looking for the hosts and other files in
> %windir%\system32\drivers\etc
> or are there some versions, situations or configurations where it looks for
> those fi
35 matches
Mail list logo
