XYplorer Beta Club

admin wrote:

zer0 wrote:I am still not entirely clear -- is the purpose of XYcopy 2.0 to allow more flexibility as far as copying is concerned rather than improvement of how fast files are actually copied? Or is the latter reserved for XYcopy 3.0?

Both, but for now I focused on flexibility and safety.

I sure could have used a speed improvement when I was shifting hundreds of gigabytes between drives over the weekend. I didn't really want it to take hours that it did.

zer0 wrote:

admin wrote:

zer0 wrote:I am still not entirely clear -- is the purpose of XYcopy 2.0 to allow more flexibility as far as copying is concerned rather than improvement of how fast files are actually copied? Or is the latter reserved for XYcopy 3.0?

Both, but for now I focused on flexibility and safety.

I sure could have used a speed improvement when I was shifting hundreds of gigabytes between drives over the weekend. I didn't really want it to take hours that it did.

Did it seem slower than the Windows Shell file functions and if so, by how much?

nas8e9 wrote:Did it seem slower than the Windows Shell file functions and if so, by how much?

I don't use kernel copy mechanism, so shell copy would have been used. Using XY, however, did yield an impression of it being a more laboured job: frequent lack of response from the progress window, etc

zer0 wrote:

nas8e9 wrote:Did it seem slower than the Windows Shell file functions and if so, by how much?

I don't use kernel copy mechanism, so shell copy would have been used. Using XY, however, did yield an impression of it being a more laboured job: frequent lack of response from the progress window, etc

Are you saying that the Windows Shell file functions when called from XYcopy.exe (i.e. backgrounded but without using Custom Copy) function worse than when called from Windows Explorer?

nas8e9 wrote:Are you saying that the Windows Shell file functions when called from XYcopy.exe (i.e. backgrounded but without using Custom Copy) function worse than when called from Windows Explorer?

That has indeed been my experience with it.

zer0 wrote:

nas8e9 wrote:Are you saying that the Windows Shell file functions when called from XYcopy.exe (i.e. backgrounded but without using Custom Copy) function worse than when called from Windows Explorer?

That has indeed been my experience with it.

I don't know whether you also employed queuing? If not, it could be that multiple simultaneous writes to the same location, were to blame.

nas8e9 wrote:I don't know whether you also employed queuing? If not, it could be that multiple simultaneous writes to the same location, were to blame.

Queued operations are enabled, so that's not the cause.

zer0 wrote:

nas8e9 wrote:I don't know whether you also employed queuing? If not, it could be that multiple simultaneous writes to the same location, were to blame.

Queued operations are enabled, so that's not the cause.

To be clear, the stalling was of the Windows copy window but not the XYplorer window?

Could you discern, assuming the operation involved more than one file, any pattern with regard to large/small files, at the beginning/middle/end of a single file's progress or the entire progress?

Did the source and/or the target seem overwhelmed?

Was there a CPU spike?

nas8e9 wrote:To be clear, the stalling was of the Windows copy window but not the XYplorer window?

Correct.

nas8e9 wrote:Could you discern, assuming the operation involved more than one file, any pattern with regard to large/small files, at the beginning/middle/end of a single file's progress or the entire progress?

With small files, there's hardly any waiting period so it's difficult to discern. With files in hundreds of MB and going into several GB, the stalling is observed towards the end of a file's copying progress. It's as if some form of "lead out", like when writing CDs/DVDs, has to be performed and that stutters things.

nas8e9 wrote:Did the source and/or the target seem overwhelmed?

I don't think so. These are two separate drives with no programs running on them, they're used just for staging data/storage.

nas8e9 wrote:Was there a CPU spike?

There was at the beginning of the copying process and at times throughout. However, with XYcopy's affinity shared across all 4 cores even though it's not a multi-threaded application, I couldn't tell which was the core that needed to be monitored.

@zero: I can't think of a reason why the Windows Shell file operations would function differently depending on the calling application. The one thing that might come into play is rather the communication between XYcopy.exe and the Windows Shell, and/or possibly between XYcopy.exe and XYplorer.exe. OTOH, I'd expect such communication only at the beginning and end of each job, whereas you seem to describe a freeze at the end of each individual file as part of a larger job?

BTW, I know correct "filing" of posts isn't that important here, but since this has nothing to do with Custom Copy, would it be an idea to continue this in a separate thread?

nas8e9 wrote:BTW, I know correct "filing" of posts isn't that important here, but since this has nothing to do with Custom Copy, would it be an idea to continue this in a separate thread?

I don't see it as a show-stopper. If I leave it alone, the process does copy files successfully. However, the faster it happens the better. Hence my eagerness for Don move onto making custom copy/move quicker as right now, for me, it offers no advantages over normal shell copy.

FYI, Windows Explorer in Windows 8 will feature a queue-like functionality where copy jobs are consolidated and can be paused/cancelled. Full video is here: http://media.ch9.ms/ch9/3ed7/82c23e5d-b ... gh_ch9.mp4

zer0 wrote:FYI, Windows Explorer in Windows 8 will feature a queue-like functionality where copy jobs are consolidated and can be paused/cancelled. Full video is here: http://media.ch9.ms/ch9/3ed7/82c23e5d-b ... gh_ch9.mp4

Ah. First XY, then Dopus, then WE. Looks like TC is next.

admin wrote:Ah. First XY, then Dopus, then WE. Looks like TC is next.

If only this sequence was true for features that should go unmentioned

Found this today that relates to Win8 changes:
http://blogs.msdn.com/b/b8/archive/2011 ... elete.aspx
Nice to know what WE will be doing so XY can be better at it before then.