Re: ls Slow When Using /cygdrive/...

[Thorsten Kampe]

* Tim Daneliuk (Mon, 03 Jan 2011 12:57:18 -0600)
> I am having a problem with ls being VERY slow on at least
> in some circumstances.  For example, ls c:/ is quick, but 
> lc /cygdrive/c/ is very slow.

strace, Process Monitor

Thorsten


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Hello, languor bush :)

[Jermaine Bischke]

http://bit.ly/fPYrbE

Charge yourself for passion ingenuity. Cried sam weller to remain at length 
semwbff.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: FYI-- Symantec Security Warnings with setup.exe

[Larry Hall (Cygwin)]

On 1/1/2011 3:12 PM, Carl Lund wrote:

Hi--

On running Cygwin setup today, Norton Security complained about two files

tee.ext and date.exe

Norton used its SONAR (see below) to detect what it thought was a high
security risk. They claimed programs were behaving suspicious on my computer.
One thing that flagged these files was that there were less than 100 people
that have used this application. Norton did not know the origin of these
files. I don't know what to say about all this, but I thought I'd let you
know what I found. I've been using Cygwin for many years, so I'm hoping
nothing really dangerous was involved this time. Otherwise, my update seems
to have gone through.




--
Larry

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists

[Eric Blake]

On 01/04/2011 09:27 AM, David Mastronarde wrote:
> 
> When there is a directory and an executable with the same name, mv adds
> .exe when renaming the directory:
> 
> % mkdir test2
> % cd test2
> % mkdir package-3.1.1
> % touch package-3.1.1.exe
> % mv package-3.1.1 package-3.1.2
> % ls
> package-3.1.1.exe  package-3.1.2.exe/
> 
> There is also a problem when there is an executable matching the name
> being moved to:
> 
> % mv package-3.1.2.exe package-3.1.2
> % ls
> package-3.1.1.exe  package-3.1.2/
> % mv package-3.1.2 package-3.1.1
> mv: cannot move `package-3.1.2' to `package-3.1.1': Not a directory
> 
> This happens with the latest snapshot of cygwin1.dll.

You CAN'T have a directory and an executable sharing the same name on
Linux, so why should you try the same thing on cygwin?  Given that
cygwin attempts to handle '.exe' as a necessary evil, and tries to
recognize executables when the suffix is omitted, you are basically
confusing cygwin by creating a directory and an executable with the same
name.

That said, there's probably room for improvement for recognizing the
situation, and trying to be smarter when both directory and .exe
executable exist; and the patch may need to be in coreutils rather than
in cygwin1.dll (since cp is doing some extra legwork for .exe magic in
the first place).  Good thing I'm building coreutils 8.9 today :)

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists

[David Mastronarde]

On Tue, 4 Jan 2011, Eric Blake wrote:


On 01/04/2011 09:27 AM, David Mastronarde wrote:


When there is a directory and an executable with the same name, mv adds
.exe when renaming the directory:

% mkdir test2
% cd test2
% mkdir package-3.1.1
% touch package-3.1.1.exe
% mv package-3.1.1 package-3.1.2
% ls
package-3.1.1.exe  package-3.1.2.exe/

There is also a problem when there is an executable matching the name
being moved to:

% mv package-3.1.2.exe package-3.1.2
% ls
package-3.1.1.exe  package-3.1.2/
% mv package-3.1.2 package-3.1.1
mv: cannot move `package-3.1.2' to `package-3.1.1': Not a directory

This happens with the latest snapshot of cygwin1.dll.


You CAN'T have a directory and an executable sharing the same name on
Linux, so why should you try the same thing on cygwin?  Given that
cygwin attempts to handle '.exe' as a necessary evil, and tries to
recognize executables when the suffix is omitted, you are basically
confusing cygwin by creating a directory and an executable with the same
name.

That said, there's probably room for improvement for recognizing the
situation, and trying to be smarter when both directory and .exe
executable exist; and the patch may need to be in coreutils rather than
in cygwin1.dll (since cp is doing some extra legwork for .exe magic in
the first place).  Good thing I'm building coreutils 8.9 today :)

--


In my case, I am using Winzip to make an executable Zip file that ends up 
having the same name as the directory.  Every time I make a new version, I 
rename the directory as indicated.  This used to work, possibly even in 
early Cygwin 1.7


Think of this as similar to having an installer file named packagename.sh. 
Linux wouldn't confuse the directory packagename and the executable 
packagename.sh


David

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists

[Steven Hartland]

- Original Message - 
From: "David Mastronarde" 



You CAN'T have a directory and an executable sharing the same name on
Linux, so why should you try the same thing on cygwin?  Given that
cygwin attempts to handle '.exe' as a necessary evil, and tries to
recognize executables when the suffix is omitted, you are basically
confusing cygwin by creating a directory and an executable with the same
name.

That said, there's probably room for improvement for recognizing the
situation, and trying to be smarter when both directory and .exe
executable exist; and the patch may need to be in coreutils rather than
in cygwin1.dll (since cp is doing some extra legwork for .exe magic in
the first place).  Good thing I'm building coreutils 8.9 today :)

--


In my case, I am using Winzip to make an executable Zip file that ends up 
having the same name as the directory.  Every time I make a new version, I 
rename the directory as indicated.  This used to work, possibly even in 
early Cygwin 1.7


Think of this as similar to having an installer file named packagename.sh. 
Linux wouldn't confuse the directory packagename and the executable 
packagename.sh


I'd agree these latest "fixes" for handling .exe cause us problems constantly.
I really don't understand this obsession for all the special handling when it
used to work just fine as it was.

In our case when we have Linux and windows files in an archive with the same
name except the extension everything goes to pot, even tar fails to expand it
which used to work without a problem :(

Executable is a permission its not an extension so why treat a file with .exe
extension any different with the exception of when looking for a binary to
run, which is an understandable special case given the Windows environment.

It really feels like so called consistency is being enforced over functionality
which is sad as I always though cygwin's goal was to make Unix look and feel
under windows?

If this was truly the goal and given Unix doesn't prevent Unix two executable
binaries, one with no extension and one with an .exe extension coexisting then
why should cygwin?

   Regards
   Steve


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists

[Eric Blake]

On 01/04/2011 12:01 PM, Steven Hartland wrote:
> It really feels like so called consistency is being enforced over
> functionality
> which is sad as I always though cygwin's goal was to make Unix look and
> feel
> under windows?

With the Unix look and feel, do you type 'ls file' or 'ls.exe file'?
There would be a LOT of upset users if we didn't do at least some magic
for .exe.  It's an unfortunate problem of running on Windows, while
still providing apps that can be invoked from non-cygwin processes (if
we wanted, we could name cygwin binaries with no extension, just as in
Unix, but then native windows apps couldn't easily run them).

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Cygwin-1.7.7: mv appends .exe to directory if matching .exe exists

[Steven Hartland]

- Original Message - 
From: "Eric Blake" 

On 01/04/2011 12:01 PM, Steven Hartland wrote:

It really feels like so called consistency is being enforced over
functionality which is sad as I always though cygwin's goal was to make
Unix look and feel under windows?

With the Unix look and feel, do you type 'ls file' or 'ls.exe file'?
There would be a LOT of upset users if we didn't do at least some magic
for .exe.  It's an unfortunate problem of running on Windows, while
still providing apps that can be invoked from non-cygwin processes (if
we wanted, we could name cygwin binaries with no extension, just as in
Unix, but then native windows apps couldn't easily run them).


As acknowledged that's one of required special cases, but when I
expand an archive with two files on Unix I end up with two files
and not one as in the following on cygwin:-
tar -xvzf cygwin-test.tar.gz 
w/

w/ls.exe
w/ls
[r...@blade01]/tmp:
[r...@blade01]/tmp: ls -l w
total 0
-rw-r--r--+ 1 root None 0 2011-01-04 20:42 ls

So not only did I loose a file I lost the windows one, not exactly
desired behavour.

What's even more confusing for the user is that its order dependent
so if the tar extracts w/ls followed by w/ls.exe instead of w/ls.exe 
followed by w/ls you do get both files.


This always used to work just fine its only been broken in 1.7.

When I raised this when we first identified the problem we where
basically told that wasnt a valid use of cygwin so would not be
fixed, so I expect this directory problem which stems from the
same behavour will be the same as well :(

With something like cygwin there are always going to be querks and
gotyas but some of the recent "fixes" seem to taking a step backwards
breaking otherwise fine uses of this most valuable tool.

If anyone's interested in revisting this issue you'll find it under
the subject: "tar deletes .exe files on extraction" in the archives.

   Regards
   Steve


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Support for Shadow Copies Exposed As Drives?

[Leon Vanderploeg]

I didn't see an email reply to
<008801cbab56$59188f30$0b49ad...@vaultnow.com> in my email, but I did see a
reply in the forum.  I am not sure about the right way to get back to the
original item, but I'm hoping this will get it there.

Re: Cygwin Support for Shadow Copies Exposed As Drives?
From: "Larry Hall \(Cygwin\)"  
To: cygwin at cygwin dot com 
Date: Mon, 03 Jan 2011 18:17:59 -0500 
Subject: Re: Cygwin Support for Shadow Copies Exposed As Drives? 
References: <008801cbab56$59188f30$0b49ad...@vaultnow.com> 
Reply-to: cygwin at cygwin dot com 



On 1/3/2011 9:56 AM, Leon Vanderploeg wrote: 
I have hit a brick wall in the Cygwin 1.7 arena -- shadow copies exposed as
drives can no longer be accessed.  See
http://cygwin.com/ml/cygwin/2009-07/msg00954.html for an example of previous
documentation on this issue.


Are there any plans for a patch or work-around to allow an exposed shadow
drive to be accessed by a program such as rsync?


Thanks in advance, and best regards,
Leon


Have you tried a recent snapshot? 


--
Larry


Hi Larry,

Thanks for the quick reply.  I just pulled down the 2010-12-29.  It, to
failed the rsync chdir to an exposed drive.  I scanned the change logs on
all the snapshots listed on the page you suggested and I didn't see anything
on shadow copies.

Best regards,
Leon

Leon Vanderploeg
Business Data Protection, LLC
Cell:  303-877-9654




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Support for Shadow Copies Exposed As Drives?

[Larry Hall (Cygwin)]

On 1/4/2011 6:08 PM, Leon Vanderploeg wrote:

I didn't see an email reply to
<008801cbab56$59188f30$0b49ad...@vaultnow.com>  in my email, but I did see a
reply in the forum.  I am not sure about the right way to get back to the
original item, but I'm hoping this will get it there.


It did.  But it wasn't smart enough to maintain the list threading.  I believe
you're missing the "References" field but don't quote me on that.

In general, if you want a reply specifically to come to you, you have to
request it.  The list directs all replies back to the list so the easiest
way to make sure you see a response is to subscribe. ;-)





Thanks for the quick reply.  I just pulled down the 2010-12-29.  It, to
failed the rsync chdir to an exposed drive.  I scanned the change logs on
all the snapshots listed on the page you suggested and I didn't see anything
on shadow copies.


OK, it was a bit of a long-shot but I remembered some other discussion of
rsync recently and thought there might be a correlation.

--
Larry

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple