Integration of ultracopier to reactOS

[alpha_one_x86]

Hello, I'm the developper of ultracopier, I propose ultracopier as default 
copier under reactOS for the reactOS explorer.
I will activly developpe it under reactOS.
It based on Qt. Only the version 0.2.0.0 is developped for reactOS.
Screenshot:
http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[King InuYasha]

I'm pretty sure the people here don't really like frameworks like MFC,
wxWidgets, or Qt. If you want it included in ReactOS, it probably will need
to be rewritten to use standard Win32 API instead.

On Sun, Nov 1, 2009 at 2:17 PM, alpha_one_x86 <
[e-mail]> wrote:
> Hello, I'm the developper of ultracopier, I propose ultracopier as default
> copier under reactOS for the reactOS explorer.
> I will activly developpe it under reactOS.
> It based on Qt. Only the version 0.2.0.0 is developped for reactOS.
> Screenshot:
> http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
>
> --
> alpha_one_x86 [e-mail]
> Main developper of Ultracopier, Esourcing and server management
> IT, OS, technologies, security and business department
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[alpha_one_x86]

I'm not able to do that's, but supercopier project is in win32 only. Is in 
coorperation with ultracopier for have same protocol.
But ultracopier can by an good idea for have good copier for you explorer.

On Sunday 01 November 2009 22:12:23 King InuYasha wrote:
> I'm pretty sure the people here don't really like frameworks like MFC,
> wxWidgets, or Qt. If you want it included in ReactOS, it probably will need
> to be rewritten to use standard Win32 API instead.
>
> On Sun, Nov 1, 2009 at 2:17 PM, alpha_one_x86 <
>
> [e-mail]> wrote:
> > Hello, I'm the developper of ultracopier, I propose ultracopier as
> > default copier under reactOS for the reactOS explorer.
> > I will activly developpe it under reactOS.
> > It based on Qt. Only the version 0.2.0.0 is developped for reactOS.
> > Screenshot:
> > http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
> >
> > --
> > alpha_one_x86 [e-mail]
> > Main developper of Ultracopier, Esourcing and server management
> > IT, OS, technologies, security and business department
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[Ged Murphy]

Hi,

Unfortunately we don't include apps which aren't part of the base operating
system.
However, you can help reactos by testing your apps on the operating system
and reporting any bugs you may find.

Thanks,
Ged.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of alpha_one_x86
Sent: 01 November 2009 20:18
To: [e-mail]
Subject: [ros-dev] Integration of ultracopier to reactOS

Hello, I'm the developper of ultracopier, I propose ultracopier as default 
copier under reactOS for the reactOS explorer.
I will activly developpe it under reactOS.
It based on Qt. Only the version 0.2.0.0 is developped for reactOS.
Screenshot:
http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[alpha_one_x86]

The copy of file is base of OS, and your explorer haven't.
Note: I have ReactOS crash when I copy folder in normal mode with ultracopier, 
but no crash in debug mode.
The systray is invisible and unable to interface correctly with the reactOS 
via COM object like windows explorer.
I have less bug on wine, and no bug under windows.
Ultracopier note: I try adapte ultracopier 0.2.0.0

On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
> Hi,
>
> Unfortunately we don't include apps which aren't part of the base operating
> system.
> However, you can help reactos by testing your apps on the operating system
> and reporting any bugs you may find.
>
> Thanks,
> Ged.
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[Andrew C]

> From an end user perspective I would be frustrated if every time I

wanted to copy a file, an over bloated file copy application was
started, loading in a UI framework like QT to do it. Its unnecessary.

Reactos may be lacking now, because its alpha. That's not a reason to
slap on a million-pound-gorilla app just to replace what will be a
eventually be a standard integrated user32 (shell32?) dialog.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of alpha_one_x86
Sent: Monday, 2 November 2009 8:50 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Integration of ultracopier to reactOS

The copy of file is base of OS, and your explorer haven't.
Note: I have ReactOS crash when I copy folder in normal mode with
ultracopier, but no crash in debug mode.
The systray is invisible and unable to interface correctly with the
reactOS via COM object like windows explorer.
I have less bug on wine, and no bug under windows.
Ultracopier note: I try adapte ultracopier 0.2.0.0

On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
> Hi,
>
> Unfortunately we don't include apps which aren't part of the base 
> operating system.
> However, you can help reactos by testing your apps on the operating 
> system and reporting any bugs you may find.
>
> Thanks,
> Ged.

--
alpha_one_x86 [e-mail] Main developper of
Ultracopier, Esourcing and server management IT, OS, technologies,
security and business department

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

[Daniel Reimer]

I partially disagree. The app might be bloated, but the idea is nice. 
The typical way of windows to copy files is sometimes very ineffective. 
There are many tools which try to be faster, especially if you copy 
several small files or on one hard driver with several partitions. The 
idea of these apps could be used by default in ROS IMO.

Andrew C schrieb:
> From an end user perspective I would be frustrated if every time I
> wanted to copy a file, an over bloated file copy application was
> started, loading in a UI framework like QT to do it. Its unnecessary.
>
> Reactos may be lacking now, because its alpha. That's not a reason to
> slap on a million-pound-gorilla app just to replace what will be a
> eventually be a standard integrated user32 (shell32?) dialog.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of alpha_one_x86
> Sent: Monday, 2 November 2009 8:50 AM
> To: ReactOS Development List
> Subject: Re: [ros-dev] Integration of ultracopier to reactOS
>
> The copy of file is base of OS, and your explorer haven't.
> Note: I have ReactOS crash when I copy folder in normal mode with
> ultracopier, but no crash in debug mode.
> The systray is invisible and unable to interface correctly with the
> reactOS via COM object like windows explorer.
> I have less bug on wine, and no bug under windows.
> Ultracopier note: I try adapte ultracopier 0.2.0.0
>
> On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
> > Hi,
> >
> > Unfortunately we don't include apps which aren't part of the base
> > operating system.
> > However, you can help reactos by testing your apps on the operating
> > system and reporting any bugs you may find.
> >
> > Thanks,
> > Ged.
>
> --
> [e-mail]  Main developper of
> Ultracopier, Esourcing and server management IT, OS, technologies,
> security and business department
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[alpha_one_x86]

Lot of peaple ask real soft for do the copy. It's because soft like 
ultracopier, supercopier, teracopier, copyhandler exists.
The target is that's will by 100% integrated and transparent to the end user 
(like firefox). The compatibility with ultracopier via the catchcopy protocol 
allow use other copier use in api win32 only and asure all copier (which 
repect the protocol) interpolability.
And the style of Qt application is 100% transparent. The copy with copier like 
ultracopier boost the speed, allow better error management (resume/retry on 
error), pause, speed limitation, group the copy list for prevent lost of 
performance.
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[Daniel Reimer]

alpha_one_x86 schrieb:
> Lot of peaple ask real soft for do the copy. It's because soft like
> ultracopier, supercopier, teracopier, copyhandler exists.
> The target is that's will by 100% integrated and transparent to the end user
> (like firefox). The compatibility with ultracopier via the catchcopy protocol
> allow use other copier use in api win32 only and asure all copier (which
> repect the protocol) interpolability.
> And the style of Qt application is 100% transparent. The copy with copier like
> ultracopier boost the speed, allow better error management (resume/retry on
> error), pause, speed limitation, group the copy list for prevent lost of
> performance.

Yes, as I said, the idea behind these apps is really great, but I fear 
we wont add a app which depends on a biiig runtime like QT in here. if 
it would be plain and fas C code, sure, why not. But QT increases RAM 
usage, slows down loading of the copy screen and makes ROS depend on it. 
I hope you understand my argument, we try to keep the OS small and 
adding QT is not the way we want to go. But maybe you can help us adding 
the used algorithms and features in our code. We really would appreciate 
this. Of course the code will be on GPL BSD or LGPL as you declare it 
and your name will be in there too.

[alpha_one_x86]

On Sunday 01 November 2009 23:28:02 Daniel Reimer wrote:
> I hope you understand my argument, we try to keep the OS small and 
> adding QT is not the way we want to go. But maybe you can help us adding 
> the used algorithms and features in our code. We really would appreciate 
> this. Of course the code will be on GPL BSD or LGPL as you declare it 
> and your name will be in there too.

Yes I understand your arguement. But adpate your explorer for support advanced 
copier can by usefull and depand of nothing.
And the user which user ultracopier download it...
And other more ligth can by easy added.

I can explain my algorithm, but I have not the skill and time for program it 
in api win32.

I thinks if lot of copier/explorer use the protocol enjoye the developper to 
do copie in various language. And maybe why not, include other copier in win32 
pur like supercopier or copyhandler.
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[Thomas Bluemel]

I don't know what's so nice about the idea, I've never had the need for 
a copy utility, explorer has always done a fine job for me.  The only 
case where I had a need for something better was bulk renames, but our 
explorer could eventually integrate such functionality as well.

IMO there's absolutely no place for such a tool to be integrated in ROS.

Thomas
Daniel Reimer wrote:
> I partially disagree. The app might be bloated, but the idea is nice. 
> The typical way of windows to copy files is sometimes very ineffective. 
> There are many tools which try to be faster, especially if you copy 
> several small files or on one hard driver with several partitions. The 
> idea of these apps could be used by default in ROS IMO.
>
> Andrew C schrieb:
> > From an end user perspective I would be frustrated if every time I
> > wanted to copy a file, an over bloated file copy application was
> > started, loading in a UI framework like QT to do it. Its unnecessary.
> >
> > Reactos may be lacking now, because its alpha. That's not a reason to
> > slap on a million-pound-gorilla app just to replace what will be a
> > eventually be a standard integrated user32 (shell32?) dialog.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of alpha_one_x86
> > Sent: Monday, 2 November 2009 8:50 AM
> > To: ReactOS Development List
> > Subject: Re: [ros-dev] Integration of ultracopier to reactOS
> >
> > The copy of file is base of OS, and your explorer haven't.
> > Note: I have ReactOS crash when I copy folder in normal mode with
> > ultracopier, but no crash in debug mode.
> > The systray is invisible and unable to interface correctly with the
> > reactOS via COM object like windows explorer.
> > I have less bug on wine, and no bug under windows.
> > Ultracopier note: I try adapte ultracopier 0.2.0.0
> >
> > On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
> > > Hi,
> > >
> > > Unfortunately we don't include apps which aren't part of the base
> > > operating system.
> > > However, you can help reactos by testing your apps on the operating
> > > system and reporting any bugs you may find.
> > >
> > > Thanks,
> > > Ged.
> >
> > --
> > [e-mail]  Main developper of
> > Ultracopier, Esourcing and server management IT, OS, technologies,
> > security and business department
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[King InuYasha]

Except I doubt such functionality would ever get integrated for the simple
reason that Windows doesn't have it. Only a few things ReactOS has that
Windows didn't and it seems like those are disappearing soon (Read: virtual
desktops).

On Sun, Nov 1, 2009 at 7:12 PM, Thomas Bluemel [e-mail] wrote:
> I don't know what's so nice about the idea, I've never had the need for
> a copy utility, explorer has always done a fine job for me.  The only
> case where I had a need for something better was bulk renames, but our
> explorer could eventually integrate such functionality as well.
>
> IMO there's absolutely no place for such a tool to be integrated in ROS.
>
> Thomas
> Daniel Reimer wrote:
> > I partially disagree. The app might be bloated, but the idea is nice.
> > The typical way of windows to copy files is sometimes very ineffective.
> > There are many tools which try to be faster, especially if you copy
> > several small files or on one hard driver with several partitions. The
> > idea of these apps could be used by default in ROS IMO.
> >
> > Andrew C schrieb:
> > > From an end user perspective I would be frustrated if every time I
> > > wanted to copy a file, an over bloated file copy application was
> > > started, loading in a UI framework like QT to do it. Its unnecessary.
> > >
> > > Reactos may be lacking now, because its alpha. That's not a reason to
> > > slap on a million-pound-gorilla app just to replace what will be a
> > > eventually be a standard integrated user32 (shell32?) dialog.
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > On Behalf Of alpha_one_x86
> > > Sent: Monday, 2 November 2009 8:50 AM
> > > To: ReactOS Development List
> > > Subject: Re: [ros-dev] Integration of ultracopier to reactOS
> > >
> > > The copy of file is base of OS, and your explorer haven't.
> > > Note: I have ReactOS crash when I copy folder in normal mode with
> > > ultracopier, but no crash in debug mode.
> > > The systray is invisible and unable to interface correctly with the
> > > reactOS via COM object like windows explorer.
> > > I have less bug on wine, and no bug under windows.
> > > Ultracopier note: I try adapte ultracopier 0.2.0.0
> > >
> > > On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
> > > > Hi,
> > > >
> > > > Unfortunately we don't include apps which aren't part of the base
> > > > operating system.
> > > > However, you can help reactos by testing your apps on the operating
> > > > system and reporting any bugs you may find.
> > > >
> > > > Thanks,
> > > > Ged.
> > >
> > > --
> > > [e-mail]  Main developper of
> > > Ultracopier, Esourcing and server management IT, OS, technologies,
> > > security and business department
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > --
> > > This message has been scanned for viruses and dangerous content by
> > > MailScanner, and is believed to be clean.
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Love Nystrom]

King InuYasha wrote:
> Except I doubt such functionality would ever get integrated for the 
> simple reason that Windows doesn't have it. Only a few things ReactOS 
> has that Windows didn't and it seems like those are disappearing soon 
> (Read: virtual desktops).

I beg to disagree. Just because Microsoft sees fit to remove good 
functionality
for whatever obscure reason, there's no reason ReactOS should do the same.
Indeed just like we're not obliged to replicate the plethora of bugs in 
Windows.
Or goal is (I hope) to create something that will eventually be better, 
in that sense,
than Windows, as Microsoft has an annoying tendency to perpetuate their 
bugs!

Best Regards // Love

__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________

The message was checked by ESET Smart Security.

http://www.eset.com

[Love Nystrom]

Thomas Bluemel wrote:
> I don't know what's so nice about the idea, I've never had the need for 
> a copy utility, explorer has always done a fine job for me.

Well for starters, Windows Explorer aborts the entire copy list as soon 
as it hits
any little snag, instead of continuing with the rest of the files in the 
list.
This behavior is of course totally unacceptable, but MS won't fix it.

I think ReactOS can do better, but not at the cost of pulling in Qt et.al.
We should (naturally) use pure Win32 and native threads.

Rock on // Love

__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________

The message was checked by ESET Smart Security.

http://www.eset.com

[alpha_one_x86]

On Monday 02 November 2009 05:38:01 Love Nystrom wrote:
> Well for starters, Windows Explorer aborts the entire copy list as soon
> as it hits
> any little snag, instead of continuing with the rest of the files in the
> list.
> This behavior is of course totally unacceptable, but MS won't fix it.
>
> I think ReactOS can do better, but not at the cost of pulling in Qt et.al.
> We should (naturally) use pure Win32 and native threads.

I agrea with you.
For example if intergration of software like supercopier it's 1MB more + 2KB 
on the explorer, but need wait respect the standard (both supercopier, and 
reactOS explorer)
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[Love Nystrom]

alpha_one_x86 wrote:
> On Monday 02 November 2009 05:38:01 Love Nystrom wrote:
> > Well for starters, Windows Explorer aborts the entire copy list as soon
> > as it hits any little snag, instead of continuing with the rest of the files in the list.
> > This behavior is of course totally unacceptable, but MS won't fix it.
> >
> > I think ReactOS can do better, but not at the cost of pulling in Qt et.al.
> > We should (naturally) use pure Win32 and native threads.
>
> I agrea with you.
> For example if intergration of software like supercopier it's 1MB more + 2KB 
> on the explorer, but need wait respect the standard (both supercopier, and 
> reactOS explorer)

IMO a basic improvement can be achieved with even less.
Just a change in the (Explorer) error handling during copying of 
multiple files.
I.e continue copying instead of going belly up.

I feel like looking into it as soon as my new environment is ready,
but anyone with "knowledge of the country" and a functioning setup is of 
course
most welcome to beat me to it ;-)

Rock on // Love

__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________

The message was checked by ESET Smart Security.

http://www.eset.com

[Wesley Parish]

On Mon, 02 Nov 2009, Love Nystrom wrote:
> alpha_one_x86 wrote:
> > On Monday 02 November 2009 05:38:01 Love Nystrom wrote:
> > > Well for starters, Windows Explorer aborts the entire copy list as soon
> > > as it hits any little snag, instead of continuing with the rest of the
> > > files in the list. This behavior is of course totally unacceptable, but
> > > MS won't fix it.
> > >
> > > I think ReactOS can do better, but not at the cost of pulling in Qt
> > > et.al. We should (naturally) use pure Win32 and native threads.
> >
> > I agrea with you.
> > For example if intergration of software like supercopier it's 1MB more +
> > 2KB on the explorer, but need wait respect the standard (both
> > supercopier, and reactOS explorer)
>
> IMO a basic improvement can be achieved with even less.
> Just a change in the (Explorer) error handling during copying of
> multiple files.
> I.e continue copying instead of going belly up.
>
> I feel like looking into it as soon as my new environment is ready,
> but anyone with "knowledge of the country" and a functioning setup is of
> course
> most welcome to beat me to it ;-)

Isn't the NT code base supposed to have multi-queued IO?  to stop such 
problems?  At least that was the NT-zealots' boast during the NT-vs-OS/2 days 
in the early nineties.

Shouldn't the routine to copy hold another IO queue in hand "just in case", 
and hand the copying over to it as soon as it hits such a snag?

Mind you, I could think of additional uses for a multi-queued IO - having a 
anti-malware program kibitzing on the copying, and stalling anything that's 
questionable, while handing the copying over to Yet Another Copying IO Queue.

As has been said, there's no need to restrict ReactOS to Microsoft's lacks and 
lacksadaisicality.

just my 0.02c - don't spend it all at once!

Wesley Parish
> Rock on // Love
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4563 (20091101) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
George Kelischek - "To impress those high-tech computer types, 
tell them what an Ocarina really is: 
an animal-activated-solid-state-multi-frequency-sound-synthesizer." 
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.

[Love Nystrom]

Wesley Parish wrote:
> Isn't the NT code base supposed to have multi-queued IO?  to stop such 
> problems?  At least that was the NT-zealots' boast during the NT-vs-OS/2 days

I'd say it's one thing what the system has ability to do do, and another 
thing
entirely what Explorer does with it. Not knowing it's source, I can only say
"by the fruit shall the tree be known".
> Shouldn't the routine to copy hold another IO queue in hand "just in case", 
> and hand the copying over to it as soon as it hits such a snag?

Precisely. A fault list or whatever you want to call it.
This could then be post-processed at the option of the user.
> Mind you, I could think of additional uses for a multi-queued IO - having a 
> anti-malware program kibitzing on the copying, and stalling anything that's 
> questionable, while handing the copying over to Yet Another Copying IO Queue.

Bear in mind that there's an inherent danger in exposing the shell's 
file copying mechanism.
While it may seem a convenient way to tie in a malware scanner, it could 
be used to conveniently
inject a payload in every file the shell copies if a "plug-in" gets 
write access to the file data.
Because of this risk any "plug-in" would have to be handed just a copy 
of the data, which would
lead to terrible inefficiency due to all that redundant data copying.

Rock on // Love

[Wesley Parish]

Quoting Love Nystrom [e-mail]:
> Wesley Parish wrote:
> > Isn't the NT code base supposed to have multi-queued IO? to stop such
> > problems? At least that was the NT-zealots' boast during the
>
> NT-vs-OS/2 days
> >
>
> I'd say it's one thing what the system has ability to do do, and another
>
> thing
> entirely what Explorer does with it. Not knowing it's source, I can only
> say
> "by the fruit shall the tree be known".

I'll have to re-read the ReactOS source.  I've been doing a bit of thinking
since last night, and I think I know where to begin.
> > Shouldn't the routine to copy hold another IO queue in hand "just in
>
> case",
> > and hand the copying over to it as soon as it hits such a snag?
>
> Precisely. A fault list or whatever you want to call it.
> This could then be post-processed at the option of the user.

Indeed.  That would be very handy.
> > Mind you, I could think of additional uses for a multi-queued IO -
>
> having a
> > anti-malware program kibitzing on the copying, and stalling anything
>
> that's
> > questionable, while handing the copying over to Yet Another Copying IO
>
> Queue.
> >
>
> Bear in mind that there's an inherent danger in exposing the shell's 
> file copying mechanism.
> While it may seem a convenient way to tie in a malware scanner, it could
>
> be used to conveniently
> inject a payload in every file the shell copies if a "plug-in" gets 
> write access to the file data.
> Because of this risk any "plug-in" would have to be handed just a copy 
> of the data, which would
> lead to terrible inefficiency due to all that redundant data copying.

The MS Windows Vista DRM vistabetion.  After Longhorn, we had vistabeting. :) 
Little wonder Vista lost IO and went blind!

Little wonder Microsoft stopped giving such names.

I stand corrected. :)

Wesley Parish
> Rock on // Love
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

"Sharpened hands are happy hands.
"Brim the tinfall with mirthful bands" 
- A Deepness in the Sky, Vernor Vinge

"I me.  Shape middled me.  I would come out into hot!" 
I from the spicy that day was overcasked mockingly - it's a symbol of the 
other horizon. - emacs : meta x dissociated-press

[Love Nystrom]

As a result of this discussion I fetched the sources of both Ultra- and 
SuperCopier.
I have made a very brief review of them and want to communicate my 
impression.

While the basic idea of both are attractive, neither can be easily 
integrated in ROS
as-is because of their dependencies, Ultra depends on Qt, and Super is 
written in
Pascal and depends on Borland's VCL.
To complicate matters further both are written under the precept that 
they don't
have access to the shell source code, and therefore must employ hooking 
methods
to achieve the desired functionality. This is dead weight in the context 
of ROS.

A much simpler implementation will suffice, and it needs to be written 
in C or C++.
I have not reviewed the relevant parts of the ROS Explorer source (I 
don't really know
it's structure), but as I see it we're just in need of better error 
handling in Explorer.
We need a copy-error list to keep track of faulted copy/move operations.
When Explorer hits a snag, it should add the filepath and some flags to 
the list,
and then commence with the rest of the files.

At the conclusion of the copy/move operations, the user should be notified,
if necessary, with the list of faulted files, and given some options on 
action.
For example, the files may be added to the boot-move list in SessionManager
if they faulted because they where locked, and so on.

I would be happy to look into this myself, but unfortunately my ROS 
development
environment is currently in a shambles after multiple system crashes and 
loss of code :-/
If someone with insight in Explorer's source feel like I do about the 
nasty behavior
of dropping an entire batch because of one little snag, then please look 
into it.
Then again, as this is not a priority matter, perhaps it can wait a 
while, and
I'll do it later (I guess You're as occupied as I am).

Rock on // Love

__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________

The message was checked by ESET Smart Security.

http://www.eset.com

[alpha_one_x86]

Have you test copyhandler?
It is do in c++ with visual.
-- 
alpha_one_x86 [e-mail]
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department

[Love Nystrom]

Daniel Reimer wrote:
> There are many tools which try to be faster, especially if you copy 
> several small files or on one hard driver with several partitions.

I do believe you're thinking about xcopy. You didn't forget xcopy, did 
you ;-)
It would perhaps be a good idea to integrate the concept of packing up 
small files
in bigger blocks in memory before transfer and write, like xcopy does.

Rock on // Love

__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________

The message was checked by ESET Smart Security.

http://www.eset.com