- Original Message -
From: "Larry Hall (Cygwin)"
Here it takes about 2 - 5mins for what ever is causing the 0 size after a
find to start to happen. Prior to that after the find all dirs show 8192 for
size in an ls.
Ah, that's interesting. I see no such time-lag here.
Just to be 100
On 1/7/2011 9:39 PM, Steven Hartland wrote:
Here it takes about 2 - 5mins for what ever is causing the 0 size after a
find to start to happen. Prior to that after the find all dirs show 8192 for
size in an ls.
Ah, that's interesting. I see no such time-lag here.
$ ls -l
total 0
drwxr-xr-x
- Original Message -
From: "Larry Hall (Cygwin)"
Just NTFS I'm afraid nothing special.
You can see the behaviour with ls -l as well, as you would expect.
A simpler, which may help is:-
ls -l
drwxr-xr-x 1 test test 0 Oct 20 14:09 testdir
find testdir > /dev/null # lots of files
ls -l
drw
On 1/7/2011 9:00 PM, Steven Hartland wrote:
- Original Message - From: "Eric Blake"
On 01/07/2011 11:21 AM, Steven Hartland wrote:
What file system is this on? Someone else reported the same behavior
for "Samba share on QNX through Virtual PC." - if the problem is limited
to just a subse
On Fri, Jan 7, 2011 at 4:25 PM, JonY wrote:
> IMHO rebaseall shouldn't be interacting with mingw dlls at all. Maybe it
> can check for dependencies on cygwin1.dll before rebasing?
That's the point. The mingw DLLs need to be added to rebaseall's filter pattern.
--
Problem reports: http://cy
- Original Message -
From: "Eric Blake"
On 01/07/2011 11:21 AM, Steven Hartland wrote:
What file system is this on? Someone else reported the same behavior
for "Samba share on QNX through Virtual PC." - if the problem is limited
to just a subset of (known-buggy) file systems, it would b
On 01/07/2011 06:09 PM, nyc4...@aol.com wrote:
> It appears that it crashes if LANG is not defined
>
> When function term.c:check_cygwin_console:239 is called and
> the following is evaluated with environment variable LANG undefined:
>
> if (strncmp(getenv("LANG"), "ja", 2) == 0) {
Yep, ge
nyc4...@aol.com writes:
> Bob Heckel writes:
>
>> On Wed, Jan 5, 2011 at 16:22, Christopher Faylor wrote:
>>> On Wed, Jan 05, 2011 at 04:16:37PM -0500, nyc4bosaol.com wrote:
nyc4bosaol.com writes:
Bob created a debug version of w3m for me.
Here's what I see:
The cra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2011 06:06, Daniel Colascione wrote:
> I recently ran into this issue between the new mingw64 libraries and
> rebaseall (mandatory on every Win7/Server2008R2 64-bit system I've
> seen so far, alas). A patch is described at
> http://blog.brev.nam
I recently ran into this issue between the new mingw64 libraries and
rebaseall (mandatory on every Win7/Server2008R2 64-bit system I've
seen so far, alas). A patch is described at
http://blog.brev.name/2010/09/nodejs-on-windows-7-under-cygwin.html
and works fine. Could it be merged?
Thanks,
Daniel
On Fri, Jan 7, 2011 at 7:29 AM, Eric Blake wrote:
> On 01/06/2011 06:39 PM, Daniel Colascione wrote:
>> If a POSIX path supplied to cygwin_conv_path ends in a symbolic link,
>> the returned path refers to the target of that link. Normally, that's
>> a good thing because native programs can't under
On 01/07/2011 11:21 AM, Steven Hartland wrote:
> It turns out that the value of st_size returned by a call
> to fstatat on a directory can change even though there
> have been no changes at all to said directory or its
> children.
What file system is this on? Someone else reported the same behavi
On 01/07/2011 01:06 PM, Nellis, Kenneth wrote:
> Using Cygwin 1.7.7, the following behavior started recently,
> but I can't think of any change that may be the culprit:
I can. Most likely, you recently ran setup.exe and upgraded tar.
Upstream tar includes a patch to make it more picky about stat
Would either of the following help?
-collect a network capture using Wildshark while running both the Cygwin
"cp" command and the Windows Explorer "copy" operation (or a simple Windows
cmd "cp" command).
-use Microsoft's "Process Monitor" to collect a Win32 trace while running
both the Cygwin "c
On 01/07/2011 01:12 PM, Larry W. Virden wrote:
> When considering building a basically "frozen" version of cygwin - that is to
> say, downloading, configuring, and building a disk image, then turning that
> disk
> image into a MSI for installation purposes (in an environment where this is
> bei
On 1/7/2011 3:12 PM, Larry W. Virden wrote:
When considering building a basically "frozen" version of cygwin - that is
to say, downloading, configuring, and building a disk image, then turning
that disk image into a MSI for installation purposes (in an environment where
this is being done because
When considering building a basically "frozen" version of cygwin - that is to
say, downloading, configuring, and building a disk image, then turning that
disk
image into a MSI for installation purposes (in an environment where this is
being done because users will not have Windows 7 permissions
Using Cygwin 1.7.7, the following behavior started recently,
but I can't think of any change that may be the culprit:
===BEGIN=SNIPPET
knel...@cobqdppj1 ~
$ cp /cygdrive/q/knellis/xyz ~
cp: skipping file `/cygdrive/q/knellis/xyz', as it was replaced while being
copied
knel...
Just been debugging a very strange issue where tar was
reporting "file changed as we read it" for directories
which aren't actually seeing any changes.
It turns out that the value of st_size returned by a call
to fstatat on a directory can change even though there
have been no changes at all to s
With "LANG=C.UTF-8", "man size" writes U+23AA (CURLY BRACKET
EXTENSION) characters in place of vertical bars (ASCII 0x7C).
Not only does this Unicode "Miscellaneous Technical" character
not display properly, it also seems a poor character choice
for this context.
Possibly not related, after se
On 01/06/2011 06:39 PM, Daniel Colascione wrote:
> If a POSIX path supplied to cygwin_conv_path ends in a symbolic link,
> the returned path refers to the target of that link. Normally, that's
> a good thing because native programs can't understand Cygwin links.
> But this behavior is unwanted when
21 matches
Mail list logo