From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: cygwin copy problems usb 2.0
Date: Thu, 03 Aug 2006 01:54:31 +0000
Message-Id: <080320060154.8210.44D157570002EFAE0000201222064244130A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> >I'm really seeing the non-optimized cygwin cp behaviour causing bad 
> >reputation, which could be easily patched and maybe even accepted 
> >upstream. Who knows. Eric what do think? Would it be worthful to think 
> >about?

I don't really want to maintain a Windows API patch, and doubt that
it would be accepted upstream.  Now if there were something more
POSIX-y that we could do to speed things up, such as posix_fadvise,
which cygwin could translate into whatever Windows API hooks that
would improve the situation, then that would be the way to go.

> 
> If this is what you want then you should look into a non-cygwin
> solution.  There are a couple of projects which provide GNU tools for
> Windows without resorting to something like the Cygwin DLL.

Agreed.  My other big worry is that I have no control over whether
using straight Windows API will violate other POSIX assumptions,  thus
making cp (and mv) noncompliant.  I am not a fan of mixing cygwin and
non-cygwin APIs when it can be helped.

That said, if someone else comes up with a potential patch, I will
certainly review it.  But it is not my highest priority right now.

-- 
Eric Blake


--
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/