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 reports:
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?
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...
--
View this message in context:
http://www.nabble.com/cygwin-copy
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
Sent
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
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 file (.tar.gz) o
> 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 here I assume
it's a native Windows ap
On Tue, Oct 15, 2002 at 08:08:43AM -0700, Michael A Chase wrote:
>On Tue, 15 Oct 2002 07:37:46 -0700 Randall R Schulz <[EMAIL PROTECTED]> wrote:
>
>> % cygcheck mount
>> Found: D:\cygwin\bin\mount.exe
>> D:\cygwin\bin\mount.exe
>>D:\cygwin\bin\cygwin1.dll
>> D:\WINNT\System32\KERNEL32.dll
Folks:
On Tue, Oct 15, 2002 Igor Pechtchanski wrote:
> On Tue, 15 Oct 2002, Michael A Chase wrote:
> > You could also create restore_mounts.bat the same way and run it in a MSDOS
> > window. The mount command does not depend on cygwin1.dll and the `mount
> > -m` output should work under MSDOS 's
On Tue, 15 Oct 2002 10:38:15 -0400 (EDT) Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Oct 2002, Michael A Chase wrote:
>
>> You could also create restore_mounts.bat the same way and run it in a MSDOS
> > window. The mount command does not depend on cygwin1.dll and the `mount
> > -m
On Tue, 15 Oct 2002 07:37:46 -0700 Randall R Schulz <[EMAIL PROTECTED]> wrote:
> % cygcheck mount
> Found: D:\cygwin\bin\mount.exe
> D:\cygwin\bin\mount.exe
>D:\cygwin\bin\cygwin1.dll
> D:\WINNT\System32\KERNEL32.dll
>D:\WINNT\System32\NTDLL.DLL
>
> Does this not mean that the m
On Tue, 15 Oct 2002, Michael A Chase wrote:
> On Tue, 15 Oct 2002 09:51:01 -0400 (EDT) Igor Pechtchanski <[EMAIL PROTECTED]>
>wrote:
>
> > It's interesting that all three replies to this message mentioned the
> > registry... While Vince should only have mentioned that it's *currently*
> > held
Michael,
% cygcheck mount
Found: D:\cygwin\bin\mount.exe
D:\cygwin\bin\mount.exe
D:\cygwin\bin\cygwin1.dll
D:\WINNT\System32\KERNEL32.dll
D:\WINNT\System32\NTDLL.DLL
Does this not mean that the mount command does use Cygwin1.dll?
Randall Schulz
Mountain View, CA USA
At 07:00 20
On Tue, 15 Oct 2002 09:51:01 -0400 (EDT) Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
> It's interesting that all three replies to this message mentioned the
> registry... While Vince should only have mentioned that it's *currently*
> held in the registry, Pavel actually recommended exporting it
It's interesting that all three replies to this message mentioned the
registry... While Vince should only have mentioned that it's *currently*
held in the registry, Pavel actually recommended exporting it. As I've
been mildly chided for this before, here's an equivalent registry-free
solution:
It's in registry under HKEY_LOCAL_MACHINE/Software/Cygnus Solutions/mounts
v2.
Export it from machine where you originally installed it then import on new
machine (change if necessary).
> -Original Message-
> From: David Široký [mailto:[EMAIL PROTECTED]]
> Sent: Tue, October 15, 2002 11:
> Where or how do I set the path of cygwin root up?
Or just re-run http://cygwin.com/setup.exe. It will "know" after scanning
your new location that nothing new is required (so there'll be no
time-consuming downloads) but it will also re-set the registry as required,
which is what has been left o
search the mailing list for defalut mounts, there was a discussion about
this quite recently. (its all held in the registry and can be retored using
the 'mount' command
> -Original Message-
> From: David Široký [mailto:[EMAIL PROTECTED]]
> Sent: 15 October 2002 10:01
> To: [EMAIL PROTECTE
35 matches
Mail list logo
