Discussion:
ls output still truncated
Chuck
2007-02-20 18:21:28 UTC
Permalink
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.

One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Ken Shaffer
2007-02-20 18:42:49 UTC
Permalink
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably.
Well, I ran sum -r (I'm running cygwin 1.5.24):

~$ sum -r /bin/ls.exe /bin/cygwin1.dll
08756 96 /bin/ls.exe
59473 1830 /bin/cygwin1.dll

You might do the same and see if there is perhaps a different ls being run.

You could also try fully qualifying the path to ls:

/bin/ls --color=none /bin

A portion of my cygcheck -svr shows:

Cygwin DLL version info:
DLL version: 1.5.24
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 156
Shared data: 4
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Wed Jan 31 10:57:51 CET 2007
CVS tag: cr-0x5f1
Shared id: cygwin1S4

I would wager that something is really hosed on your system, since
none of the rest of us seem to have this problem.

Ken
Chuck
2007-02-20 18:55:15 UTC
Permalink
Post by Ken Shaffer
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably.
~$ sum -r /bin/ls.exe /bin/cygwin1.dll
08756 96 /bin/ls.exe
59473 1830 /bin/cygwin1.dll
You might do the same and see if there is perhaps a different ls being run.
/bin/ls --color=none /bin
DLL version: 1.5.24
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 156
Shared data: 4
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Build date: Wed Jan 31 10:57:51 CET 2007
CVS tag: cr-0x5f1
Shared id: cygwin1S4
I would wager that something is really hosed on your system, since
none of the rest of us seem to have this problem.
Ken
I would think is something were really hosed, I've be having other
problems, but I'm not. The only thing that isn't working - windows or
cygwin - is ls.exe.

My "sum -r" output, and the portion of the output from "cygcheck -svr"
on my box are 100% identical to yours.

Other than removing the ls.exe binary and converting it to a symlink for
dir, I don't know what to do.

Can you please check these md5sum's for me?

$ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe
60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe
Ken Shaffer
2007-02-20 19:13:50 UTC
Permalink
Post by Chuck
Can you please check these md5sum's for me?
$ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe
60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe
Same.

~$ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe
60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe

Ken
Larry Hall (Cygwin)
2007-02-20 19:24:49 UTC
Permalink
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Can you trim it down to a simple directory with a file or two? If not,
can you determine what is key to making it happen? You may have mentioned
these before but I don't recall and didn't see them in my review of the
thread:

- Do you see this when running locally? From ssh?
- Does it reproduce in bash? In bash run from cmd.exe?
- Is CYGWIN environment variable still unset?
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Post by Chuck
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Chuck
2007-02-20 20:02:17 UTC
Permalink
Post by Larry Hall (Cygwin)
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Can you trim it down to a simple directory with a file or two? If not,
can you determine what is key to making it happen? You may have mentioned
these before but I don't recall and didn't see them in my review of the
- Do you see this when running locally? From ssh?
- Does it reproduce in bash? In bash run from cmd.exe?
- Is CYGWIN environment variable still unset?
Most of the info was in a thread from last week but in answer to the
immediate questions...

Nothing seems to be key to making it happen. It *usually* happens the
first 3 or 4 times I try to ls a directory, then it works 90% of the
time for that directory. The /cygdrive directory

I see it running locally. Local is the only way I run. I do not have
sshd installed.

It reproduces in bash and pdksh whether I run from cmd.exe or xterm.

If run from cmd.exe using the batch file, CYGWIN=tty. If run via an
xterm it's not set.

I can reproduce the problem even on a directory with only one file.

Thanks for looking into this.
Larry Hall (Cygwin)
2007-02-20 20:15:48 UTC
Permalink
Post by Chuck
Post by Larry Hall (Cygwin)
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Can you trim it down to a simple directory with a file or two? If not,
can you determine what is key to making it happen? You may have mentioned
these before but I don't recall and didn't see them in my review of the
- Do you see this when running locally? From ssh?
- Does it reproduce in bash? In bash run from cmd.exe?
- Is CYGWIN environment variable still unset?
Most of the info was in a thread from last week but in answer to the
immediate questions...
Nothing seems to be key to making it happen. It *usually* happens the
first 3 or 4 times I try to ls a directory, then it works 90% of the
time for that directory. The /cygdrive directory
I see it running locally. Local is the only way I run. I do not have
sshd installed.
It reproduces in bash and pdksh whether I run from cmd.exe or xterm.
If run from cmd.exe using the batch file, CYGWIN=tty. If run via an
xterm it's not set.
I can reproduce the problem even on a directory with only one file.
Can you send the output of a successful 'ls -l' from within a directory
with one file and then the strace of a failing case of 'ls' within this
directory and a non-failing case of the same to the list?

Does it work fine without 'tty' set for bash run at cmd.exe?
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Post by Chuck
Q: Are you sure?
Post by Larry Hall (Cygwin)
A: Because it reverses the logical flow of conversation.
Post by Chuck
Q: Why is top posting annoying in email?
Chuck
2007-02-20 20:59:06 UTC
Permalink
Post by Larry Hall (Cygwin)
Post by Chuck
Post by Larry Hall (Cygwin)
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Can you trim it down to a simple directory with a file or two? If not,
can you determine what is key to making it happen? You may have mentioned
these before but I don't recall and didn't see them in my review of the
- Do you see this when running locally? From ssh?
- Does it reproduce in bash? In bash run from cmd.exe?
- Is CYGWIN environment variable still unset?
Most of the info was in a thread from last week but in answer to the
immediate questions...
Nothing seems to be key to making it happen. It *usually* happens the
first 3 or 4 times I try to ls a directory, then it works 90% of the
time for that directory. The /cygdrive directory
I see it running locally. Local is the only way I run. I do not have
sshd installed.
It reproduces in bash and pdksh whether I run from cmd.exe or xterm.
If run from cmd.exe using the batch file, CYGWIN=tty. If run via an
xterm it's not set.
I can reproduce the problem even on a directory with only one file.
Can you send the output of a successful 'ls -l' from within a directory
with one file and then the strace of a failing case of 'ls' within this
directory and a non-failing case of the same to the list?
Does it work fine without 'tty' set for bash run at cmd.exe?
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory. Please let me know if you see anything. In
the mean time I'm going to refresh myself on the use of gcc and gdb and
see if I can trace the execution of ls. Like I said in another post
though, it's been a *very* long time since I've done any C programming
and I don't think I've ever used the gnu debugger.
Frodak Baksik
2007-02-20 21:13:32 UTC
Permalink
Post by Chuck
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory. Please let me know if you see anything. In
the mean time I'm going to refresh myself on the use of gcc and gdb and
see if I can trace the execution of ls. Like I said in another post
though, it's been a *very* long time since I've done any C programming
and I don't think I've ever used the gnu debugger.
<SNIP TRACE DATA>

I'm using gmail and the traces are embedded in the email, so forgive
me if I'm way off base.

If these are the full traces, then when it works ls runs fine. When
it doesn't work ls was killed somehow. In the first trace file the
Post by Chuck
62 11096 [main] ls 1036 normalize_win32_path: c:\Program Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program Files\QuickTime\QTSystem\)
Notice that ls never performed a closedir or wrote any data out.
Post by Chuck
167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60)
178 42094 [main] ls 3048 closedir: 0 = closedir (0xA0000)
113 42207 [main] ls 3048 fhandler_base::fstat: here
59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20)
372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1
65 42703 [main] ls 3048 sig_send: wakeup 0x6C8
68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8
66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8
72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34
105 43014 [main] ls 3048 fhandler_base::write: binary write
Which got to the point where ls closed the dir handle and actually
wrote some data.

I don't know what would kill a process like that? Or am I just not
seeing all of the data?

--
Frodak
Chuck
2007-02-20 21:17:36 UTC
Permalink
Post by Frodak Baksik
Post by Chuck
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory. Please let me know if you see anything. In
the mean time I'm going to refresh myself on the use of gcc and gdb and
see if I can trace the execution of ls. Like I said in another post
though, it's been a *very* long time since I've done any C programming
and I don't think I've ever used the gnu debugger.
<SNIP TRACE DATA>
I'm using gmail and the traces are embedded in the email, so forgive
me if I'm way off base.
If these are the full traces, then when it works ls runs fine. When
it doesn't work ls was killed somehow. In the first trace file the
Post by Chuck
62 11096 [main] ls 1036 normalize_win32_path: c:\Program
Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program
Files\QuickTime\QTSystem\)
Notice that ls never performed a closedir or wrote any data out.
Post by Chuck
167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60)
178 42094 [main] ls 3048 closedir: 0 = closedir (0xA0000)
113 42207 [main] ls 3048 fhandler_base::fstat: here
59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20)
372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1
65 42703 [main] ls 3048 sig_send: wakeup 0x6C8
68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8
66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8
72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34
105 43014 [main] ls 3048 fhandler_base::write: binary write
Which got to the point where ls closed the dir handle and actually
wrote some data.
I don't know what would kill a process like that? Or am I just not
seeing all of the data?
--
Frodak
I think it's actually something to do with the gmane interface that I
post to. I attach the files with Thunderbird but when they post to the
list, they end up being embedded. Apologies but there doesn't seem to be
any way for me to control that.

You are seeing things correctly. This has been the problem all along.
When ls fails, it just dies right in the middle, but exits with a 0
error code.
Matthew Woehlke
2007-02-20 21:42:14 UTC
Permalink
Post by Chuck
I think it's actually something to do with the gmane interface that I
post to. I attach the files with Thunderbird but when they post to the
list, they end up being embedded. Apologies but there doesn't seem to be
any way for me to control that.
No, it's working right... your files are attached with whatever MIME
type causes them to be 'previewed', which is The Right Way according to
past discussion.
--
Matthew
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
-- from a story by Feech
Larry Hall (Cygwin)
2007-02-20 21:23:57 UTC
Permalink
Post by Frodak Baksik
Post by Chuck
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory. Please let me know if you see anything. In
the mean time I'm going to refresh myself on the use of gcc and gdb and
see if I can trace the execution of ls. Like I said in another post
though, it's been a *very* long time since I've done any C programming
and I don't think I've ever used the gnu debugger.
<SNIP TRACE DATA>
I'm using gmail and the traces are embedded in the email, so forgive
me if I'm way off base.
If these are the full traces, then when it works ls runs fine. When
it doesn't work ls was killed somehow. In the first trace file the
Post by Chuck
62 11096 [main] ls 1036 normalize_win32_path: c:\Program
Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program
Files\QuickTime\QTSystem\)
Notice that ls never performed a closedir or wrote any data out.
Post by Chuck
167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60)
178 42094 [main] ls 3048 closedir: 0 = closedir (0xA0000)
113 42207 [main] ls 3048 fhandler_base::fstat: here
59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20)
372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1
65 42703 [main] ls 3048 sig_send: wakeup 0x6C8
68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8
66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8
72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34
105 43014 [main] ls 3048 fhandler_base::write: binary write
Which got to the point where ls closed the dir handle and actually
wrote some data.
I don't know what would kill a process like that? Or am I just not
seeing all of the data?
No, you're seeing all the data sent.

Chuck, what's the error code returned from each case?
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Post by Frodak Baksik
Q: Are you sure?
Post by Chuck
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Chuck
2007-02-20 21:34:51 UTC
Permalink
Post by Larry Hall (Cygwin)
Post by Frodak Baksik
Post by Chuck
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory. Please let me know if you see anything. In
the mean time I'm going to refresh myself on the use of gcc and gdb and
see if I can trace the execution of ls. Like I said in another post
though, it's been a *very* long time since I've done any C programming
and I don't think I've ever used the gnu debugger.
<SNIP TRACE DATA>
I'm using gmail and the traces are embedded in the email, so forgive
me if I'm way off base.
If these are the full traces, then when it works ls runs fine. When
it doesn't work ls was killed somehow. In the first trace file the
Post by Chuck
62 11096 [main] ls 1036 normalize_win32_path: c:\Program
Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program
Files\QuickTime\QTSystem\)
Notice that ls never performed a closedir or wrote any data out.
Post by Chuck
167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60)
178 42094 [main] ls 3048 closedir: 0 = closedir (0xA0000)
113 42207 [main] ls 3048 fhandler_base::fstat: here
59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20)
372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1
65 42703 [main] ls 3048 sig_send: wakeup 0x6C8
68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8
66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8
72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34
105 43014 [main] ls 3048 fhandler_base::write: binary write
Which got to the point where ls closed the dir handle and actually
wrote some data.
I don't know what would kill a process like that? Or am I just not
seeing all of the data?
No, you're seeing all the data sent.
Chuck, what's the error code returned from each case?
Error code in both cases is 0.
Larry Hall (Cygwin)
2007-02-20 21:18:18 UTC
Permalink
Post by Chuck
Post by Larry Hall (Cygwin)
Can you send the output of a successful 'ls -l' from within a directory
with one file and then the strace of a failing case of 'ls' within this
directory and a non-failing case of the same to the list?
Does it work fine without 'tty' set for bash run at cmd.exe?
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory.
What is the path to this directory? What's the listing ('ls -l') of this
directory? What's the difference, if any, when 'ls' is run in this
directory without 'tty' set in the CYGWIN environment variable (this needs
to *not* be set at shell start-up time)?
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Post by Chuck
Q: Are you sure?
Post by Larry Hall (Cygwin)
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Chuck
2007-02-20 21:58:36 UTC
Permalink
Post by Larry Hall (Cygwin)
Post by Chuck
Post by Larry Hall (Cygwin)
Can you send the output of a successful 'ls -l' from within a directory
with one file and then the strace of a failing case of 'ls' within this
directory and a non-failing case of the same to the list?
Post by Larry Hall (Cygwin)
Does it work fine without 'tty' set for bash run at cmd.exe?
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory.
What is the path to this directory? What's the listing ('ls -l') of this
directory? What's the difference, if any, when 'ls' is run in this
directory without 'tty' set in the CYGWIN environment variable (this needs
to *not* be set at shell start-up time)?
The path to the directory is /cygwin/home/CHamilto/test. The ls -l
listing (when it works) is...

$ ls -l
total 49120
drwxr-xr-x+ 2 CHamilto Domain Users 0 Feb 20 15:54 ./
drwxr-xr-x+ 18 CHamilto Domain Users 0 Feb 20 15:54 ../
-rwxr-xr-x 1 CHamilto Domain Users 50297564 Feb 20 12:22 test.wav*
$ pwd
/home/CHamilto/test

CYGWIN was not set when I ran it as you can see below.

$ set | grep CYGWIN
$

I downloaded the source for coreutils and see that in ls.c the same
source code is used to compile ls, dir, and vdir. The strange thing is
that dir and vdir never fail. Only ls does. I haven't figured out how to
compile with the debugging info yet.
Larry Hall (Cygwin)
2007-02-20 23:48:49 UTC
Permalink
I downloaded the source for coreutils and see that in ls.c the same source
code is used to compile ls, dir, and vdir. The strange thing is that dir
and vdir never fail. Only ls does. I haven't figured out how to compile
with the debugging info yet.
make CFLAGS="-g"
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Gary Johnson
2007-02-20 20:09:32 UTC
Permalink
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
At this point, I'd be inclined to get the source for ls, build a
version with debugging enabled, and use gdb. I've never used gdb
under Cygwin, so there may be some reason it isn't as useful under
Cygwin as it is under, say, Linux. In that case, you could add a
few printfs to see what's happening.

Just my $0.02,
Gary
--
Gary Johnson | Agilent Technologies
***@spk.agilent.com | Wireless Division
| Spokane, Washington, USA
Larry Hall (Cygwin)
2007-02-20 20:20:53 UTC
Permalink
Post by Gary Johnson
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
At this point, I'd be inclined to get the source for ls, build a
version with debugging enabled, and use gdb. I've never used gdb
under Cygwin, so there may be some reason it isn't as useful under
Cygwin as it is under, say, Linux. In that case, you could add a
few printfs to see what's happening.
There's no great difference between gdb on Cygwin vs Linux.

Doing some debugging locally is by far the best way to gain some insight
as to what's going on. Good advice.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Post by Gary Johnson
Q: Are you sure?
Post by Chuck
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Chuck
2007-02-20 20:52:44 UTC
Permalink
Post by Gary Johnson
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
At this point, I'd be inclined to get the source for ls, build a
version with debugging enabled, and use gdb. I've never used gdb
under Cygwin, so there may be some reason it isn't as useful under
Cygwin as it is under, say, Linux. In that case, you could add a
few printfs to see what's happening.
Just my $0.02,
Gary
I haven't done this sort of thing in about 10 years, but that was
actually my next thought too.
Cesar Strauss
2007-02-20 21:48:24 UTC
Permalink
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Interesting fact that dir.exe works and ls.exe does not. Inspecting the
source, the one and only difference between the two is:

-- ls-ls.c begin --
#include "ls.h"
int ls_mode = LS_LS;
-- ls-ls.c end --

-- ls-dir.c begin --
#include "ls.h"
int ls_mode = LS_MULTI_COL;
-- ls-dir.c end --

For all purposes, they should behave exactly the same, except for the
output format.

It's a shot in the dark, but could you try:
1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails?
2) Does ls -l also fails?
3) Does vdir.exe fails?

Do you have antivirus or webcam software running? They are known for
causing random problems in Cygwin apps.

Cesar
Chuck
2007-02-20 22:53:02 UTC
Permalink
Post by Cesar Strauss
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Interesting fact that dir.exe works and ls.exe does not. Inspecting the
-- ls-ls.c begin --
#include "ls.h"
int ls_mode = LS_LS;
-- ls-ls.c end --
-- ls-dir.c begin --
#include "ls.h"
int ls_mode = LS_MULTI_COL;
-- ls-dir.c end --
For all purposes, they should behave exactly the same, except for the
output format.
1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails?
2) Does ls -l also fails?
3) Does vdir.exe fails?
Do you have antivirus or webcam software running? They are known for
causing random problems in Cygwin apps.
Cesar
No webcam software. I have av software but it's the same av software
that's been running for 2 years and never caused a problem before -
Symantec 10.0.2.2002. I can't remove it. It's a corporate PC and it's
against corporate policy to remove it.

I created myls as you said and can not get it to fail. You may be on to
something! I just ran myls 30 times in a row on the one directory that
ls chokes on most often - /cygdrive. It didn't fail once. Ls on the
other hand fails almost 50% of the time.
Cesar Strauss
2007-02-20 23:52:14 UTC
Permalink
Post by Chuck
Post by Cesar Strauss
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Interesting fact that dir.exe works and ls.exe does not. Inspecting the
-- ls-ls.c begin --
#include "ls.h"
int ls_mode = LS_LS;
-- ls-ls.c end --
-- ls-dir.c begin --
#include "ls.h"
int ls_mode = LS_MULTI_COL;
-- ls-dir.c end --
For all purposes, they should behave exactly the same, except for the
output format.
1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails?
2) Does ls -l also fails?
3) Does vdir.exe fails?
Do you have antivirus or webcam software running? They are known for
causing random problems in Cygwin apps.
Cesar
No webcam software. I have av software but it's the same av software
that's been running for 2 years and never caused a problem before -
Symantec 10.0.2.2002. I can't remove it. It's a corporate PC and it's
against corporate policy to remove it.
I created myls as you said and can not get it to fail. You may be on to
something! I just ran myls 30 times in a row on the one directory that
ls chokes on most often - /cygdrive. It didn't fail once. Ls on the
other hand fails almost 50% of the time.
The only pattern I can see, strange as it may be, is that somehow any
process whose name is ls.exe is being killed randomly in your system.

Try this:
1) Copy dir.exe to ls.exe
2) Copy du.exe to ls.exe
3) Copy myls.exe to /tmp/ls.exe
Does the newly copied ls.exe fails in each case?

Cesar
Chuck
2007-02-21 15:02:11 UTC
Permalink
Post by Cesar Strauss
Post by Chuck
Post by Cesar Strauss
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
Interesting fact that dir.exe works and ls.exe does not. Inspecting the
-- ls-ls.c begin --
#include "ls.h"
int ls_mode = LS_LS;
-- ls-ls.c end --
-- ls-dir.c begin --
#include "ls.h"
int ls_mode = LS_MULTI_COL;
-- ls-dir.c end --
For all purposes, they should behave exactly the same, except for the
output format.
1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails?
2) Does ls -l also fails?
3) Does vdir.exe fails?
Do you have antivirus or webcam software running? They are known for
causing random problems in Cygwin apps.
Cesar
No webcam software. I have av software but it's the same av software
that's been running for 2 years and never caused a problem before -
Symantec 10.0.2.2002. I can't remove it. It's a corporate PC and it's
against corporate policy to remove it.
I created myls as you said and can not get it to fail. You may be on to
something! I just ran myls 30 times in a row on the one directory that
ls chokes on most often - /cygdrive. It didn't fail once. Ls on the
other hand fails almost 50% of the time.
The only pattern I can see, strange as it may be, is that somehow any
process whose name is ls.exe is being killed randomly in your system.
1) Copy dir.exe to ls.exe
2) Copy du.exe to ls.exe
3) Copy myls.exe to /tmp/ls.exe
Does the newly copied ls.exe fails in each case?
Cesar
In each case, ls fails. Is there any way to determine what would
randomly be killing ls? Symantec AV is the only thing I can think of
that might do it but there's no indication in any of it's logs that
it's taken an action against ls.exe.

I did a quick google search on "virus +ls.exe" and found lots of hits.
There's apparently some malware that creates a file named ls.exe which
is making me even more suspicious that this it's Symantec trapping what
it thinks is a virus. I've configured Symantec to ignore everything
under the c:\cygwin directory but it's still happening. Perhaps a reboot
is in order.
Eric Blake
2007-02-20 22:08:17 UTC
Permalink
Post by Chuck
Can you please check these md5sum's for me?
$ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe
64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe
60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe
/bin and /usr/bin are typically the same directory (accessed
via separate mount points) unless you have altered the default
mounts. And ls vs. dir are both built from the same source
files in coreutils; the difference is that ls has a different set
of builtin defaults than dir. As for why your output is getting
truncated, I have no idea.
--
Eric Blake
volunteer cygwin coreutils maintainer
Chuck
2007-03-01 13:57:10 UTC
Permalink
Post by Chuck
Folks I could really use some help here. I still cannot get the ls
command to work reliably. It worked for years and about two weeks ago
started sputtering. I have completely unstalled all cygwin packages,
deleted the directories, and reinstalled from scratch. Even just
installing the bare mimimum packages and running a bash shell without X
or even a .profile, ls still fails to output anything 50% of the time.
One other observation I've made is there's a similar program named
"dir.exe" in the /usr/bin directory. It seems to do pretty much the same
thing as ls. In fact the file sizes and timestamps are even the same. It
works every time. I could just alias ls=/usr/bin/dir but that seems more
like a work-around rather than fixing the real problem. Can anyone help
with this? TIA
For anyone interested, the problem turned out not to be caused by either
anti-virus or anyti-spyware software, but rather it was LanDesk. When I
stopped the "LANDesk Software Monitoring" service, the problem went
away. When I restarted it, it returned. Thanks to all who helped in
pointing me in the right direction. It just took some time to figure out
which program it was.

Continue reading on narkive:
Loading...