X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Chuck Subject: Re: ls output still truncated Date: Wed, 21 Feb 2007 10:02:11 -0500 Lines: 86 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Note-from-DJ: This may be spam Cesar Strauss wrote: > Chuck wrote: >> Cesar Strauss wrote: >>> Chuck wrote: >>>> 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 >>> >>> >> >> 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 > > 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. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/