Corinna Vinschen cygwin.com> writes:
>
> Does cp already use ftruncate?
Yes, when copying from one regular file to another, cp (and mv and install,
which share the same code for file copies) uses ftruncate. But it currently
only uses it for creating holes at the tail end of sparse files, rel
On Aug 3 19:08, Eric Blake wrote:
> >
> > Theoretically, it's possible to implement posix_fadvise only for offset=0
> > and length=, and have it fail with EINVAL otherwise...
> > While technically not POSIX-compliant, it would still allow for better
> > implementation of things like copy...
>
>
>
> Theoretically, it's possible to implement posix_fadvise only for offset=0
> and length=, and have it fail with EINVAL otherwise...
> While technically not POSIX-compliant, it would still allow for better
> implementation of things like copy...
Even better, have it return 0 for success but do
On Aug 3 13:22, Igor Peshansky wrote:
> On Thu, 3 Aug 2006, Corinna Vinschen wrote:
> > On Aug 3 01:54, Eric Blake wrote:
> > > 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,
> >
> > posix_fadvise can't be
On Thu, 3 Aug 2006, Corinna Vinschen wrote:
> On Aug 3 01:54, Eric Blake wrote:
> > > >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
On Aug 3 01:54, Eric Blake wrote:
> > >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 m
On Thu, Aug 03, 2006 at 09:54:13AM +0200, Reini Urban wrote:
>Christopher Faylor schrieb:
>>On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote:
>>>Christopher Faylor schrieb:
On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
>On Jul 27 13:48, aldana wrote:
>>isn
Christopher Faylor schrieb:
On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote:
Christopher Faylor schrieb:
On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
On Jul 27 13:48, aldana wrote:
isn't there a possibitly that cygwin provides a quicker
cp-implementation? i m
> >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
On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote:
>Christopher Faylor schrieb:
>>On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
>>>On Jul 27 13:48, aldana wrote:
isn't there a possibitly that cygwin provides a quicker
cp-implementation? i mean 4 minutes for a
Christopher Faylor schrieb:
On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
On Jul 27 13:48, aldana wrote:
isn't there a possibitly that cygwin provides a quicker
cp-implementation? i mean 4 minutes for a copy of 70MB to a memstick
(instead of CopyFile() 20 sec.) is not reall
yes that's the most obvious solution for my problem.
--
View this message in context:
http://www.nabble.com/cygwin-copy-problems-usb-2.0-tf2009189.html#a5537963
Sent from the Cygwin Users forum at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem re
Christopher Faylor wrote:
> A few weeks ago there was a guy in libc-alpha mailing list complaining
> that glibc's API wasn't as rich and powerful as what is found on Windows.
>
> As far as I know he's still alive.
You made my day!
Regards
mks
--
Unsubscribe info: http://cygwin.com/ml/#uns
You wrote on Thursday, July 27, 2006 7:40 PM:
> ... which is plain too long to include it in my script.
Have you tried "copy" instead of "cp"? It's plain Windows
and it's a command line tool. I don't know whether it uses
CopyFile(), but it might be worth a try, right?
Cheers,
Jan.
--
Un
On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
>On Jul 27 13:48, aldana wrote:
>>isn't there a possibitly that cygwin provides a quicker
>>cp-implementation? i mean 4 minutes for a copy of 70MB to a memstick
>>(instead of CopyFile() 20 sec.) is not really good performance. i
>>
aldana wrote:
isn't there a possibitly that cygwin provides a quicker cp-implementation?
i mean 4 minutes for a copy of 70MB to a memstick (instead of CopyFile() 20
sec.) is not really good performance.
i guess there is a reason for that...
Chris has already given you the answer but feel fre
On Jul 27 13:48, aldana wrote:
>
> isn't there a possibitly that cygwin provides a quicker cp-implementation?
> i mean 4 minutes for a copy of 70MB to a memstick (instead of CopyFile() 20
> sec.) is not really good performance.
> i guess there is a reason for that...
Right, how did you know?
ygwin-copy-problems-usb-2.0-tf2009189.html#a5528898
Sent from the Cygwin Users forum at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
On Thu, Jul 27, 2006 at 04:17:14PM -0400, Larry Hall (Cygwin) wrote:
>aldana wrote:
>>when running a little program using CopyFile() under cygwin it is about
>>as quick as totalcommander. so it must be the abstraction layer of
>>cygwin which makes copying vry slow...
>
>Not necessarily. To dr
aldana wrote:
when running a little program using CopyFile() under cygwin it is about as
quick as totalcommander. so it must be the abstraction layer of cygwin which
makes copying vry slow...
Not necessarily. To draw that conclusion, you would want to compare the
implementation of 'cp' co
when running a little program using CopyFile() under cygwin it is about as
quick as totalcommander. so it must be the abstraction layer of cygwin which
makes copying vry slow...
--
View this message in context:
http://www.nabble.com/cygwin-copy-problems-usb-2.0-tf2009189.html#a5528112
aldana wrote:
total commander is a clone of norton commander. something like midnight
commander on linux.
i thought the same: choice between usb 1.x and 2.0 is done far lower level
that cygwin can really influence it. but the difference of speed made me
consipicious.
example, copying a single f
context:
http://www.nabble.com/cygwin-copy-problems-usb-2.0-tf2009189.html#a5525767
Sent from the Cygwin Users forum at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com
> From: aldana
> Sent: Thursday, July 27, 2006 7:15 AM
> Subject: cygwin copy problems usb 2.0
>
>
> hi,
>
> i've got usb 2.0, when i copy through TotalCommander the copy
> speed is quite high.
I have no idea what a TotalCommander is, but from the context her
rting usb2.0 ?
thanks.
--
View this message in context:
http://www.nabble.com/cygwin-copy-problems-usb-2.0-tf2009189.html#a5519828
Sent from the Cygwin Users forum at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems
25 matches
Mail list logo
