Incorrect errfiles number? Or what does Errfiles refer to?

[jaso...@gmail.com]

Hey there,

Using this program for the first time (RichCopy had problems reading certain file characters)

Anyway-  I recently copied a long series of files to a backup drive.  Many files would not copy b/c of error 1117.  Possibly there are errors with the source drive.

FastCopy did the copy, but did not copy many files (because of the errors).  In the log, it gave me a list of the files it did not copy.

The list contains 218 files.

But the log states "Errfiles : 319 / ErrDirs : 0"

Why are these numbers different?  Are there files that did not copy that are not on the list?  These are media files, I doubt there are 101 hidden files on the drive.... 

Any suggestions are appreciated.  I don't want to miss copying any of files.

Thanks-

[SHIROUZU Hiroaki]

If you send the log to me, I will analyze it.

[jaso...@gmail.com]

Hey,

Sorry for the delayed reply.   Thank you for your response, appreciated!

Where could I send the log?  At the moment I'm not sure I'd want to post it directly here.

I can send this:

TotalRead  = 892,562 MiB

TotalWrite = 858,594 MiB

TotalFiles = 2,057 (51)

TotalTime  = 04:20:05

TransRate  = 55.0 MiB/s

FileRate   = 0.13 files/s

VerifyRead = 856,051 MiB

VerifyFiles= 2,057

 

Result : (ErrFiles : 319 / ErrDirs : 0)

 

What I did was I took the entire file list and copied it over to Excel.  Then I just counted the rows.  218 rows of files.   

Thanks!

[jaso...@gmail.com]

(Oop- I should add that every single file had the exact same error:)

WriteFileWait(The request could not be performed because of an I/O device error.1117) : <directory / file name>

[SHIROUZU Hiroaki]

This.

https://ipmsg.org/email2.png

[SHIROUZU Hiroaki]

I analyzed your log file.

The correct error number is 218, not 319.

FastCopy aborts to read a big file when the big file was failed to write to dest.

In the current version, the error counter is up when read-aborting is happend.

(In other words, two error counts(write and read) were reported with one big file.)

I will fix it in the next version.

[jaso...@gmail.com]

Hi,

Thanks for the quick response (again!)

I think I understand, but I did have a few questions.  So if I understand you correctly, then-

• All files had a write error.  Of those, 99 files were large enough that it hadn't finished reading when the write error occurred, and so gave a read error as well, even though there might not be an error, it's just the read was cancelled.  (Or some situation similar to this).  Is that correct?

• If all files had a write error.... Does that mean that the problem was with the destination drive??  The problem I was having with the dock should have been with the source drive.  Also, the source drive is older, and the destination drive is brand new.  If my question is right, the new/working part of my setup is where something went wrong, not the old/possibly broken part of my setup.  That seems bad for me, lol...
  

• Did you get this conclusion just from looking at the log file? I'm curious how you were able to tell.  I'm just being curious and if it's complicated, then don't worry about explaining it.  I'm just hoping to possibly learn a bit more about how to interpret the log file.  Just from looking at it I would never have guessed the result you gave.
  

-J

[SHIROUZU Hiroaki]

All the problems are in the destination drive or communication to the destination drive, not in the source drive.

This conclusion was obtained not only from analysis of logs but also from source code investigation and some experiments.

[jaso...@gmail.com]

Got it.  

I hope it's the 'communication', meaning my dock went bad.  The destination drive is brand new.  I ran some diagnostics on it, maybe I'll run a few more.

Thanks again for your help and detective work!  Very much appreciated!

-J

[jaso...@gmail.com]

Hello Shirouzu,

I noticed something recently, and thought you might be interested.

I did some more testing, and came across an observation - I think FastCopy might have difficulty when copying using a dual-bay external hard drive dock.  A device like this one:

https://smile.amazon.com/Aluminum-External-3-5-inch-Duplicator-Function/dp/B0151BDW9S/ref=sr_1_7?ie=UTF8&qid=1550625215&sr=8-7&keywords=dual+bay+external+dock

(I don't mean that exact model, I mean docks like that generally).

Long story short- I did a test copy of a large folder, and tested a lot of variables- two different docks (two companies), multiple drives, even a different power supply.  Everything copied fine, EXCEPT when copying using both drives in one dock.  When I did that, copy a large file using a single dual-bay dock, I got the exact error that I showed you previously.  A couple times.

If you want more detail about the methods/tests I ran, let me know.  Otherwise, it's something I think you might be interested in looking into, depending.

Best-

-J

[SHIROUZU Hiroaki]

I think it is your dock's problem because FastCopy uses only Win32 Standard File API.

[SHIROUZU Hiroaki]

I released v3.63 and error count problem is fixed.

[jaso...@gmail.com]

Ok, so... I don't know what the Win32 Standard File API means... but-

Without looking at my exact notes, I had:

Two dual bay docks.  One brand new, one older (the one that started giving me these problems.)

Folder of video files, about 12 Gigs

Two different source drives, and two different destination drives

Every time I copied with Fast Copy, going within the same dock, I got errors.  Both with the new dock and the old dock.

Every time I went from one dock to another dock, there were no errors.  I did:

   Front bay to front bay (1-->2 and 2-->1)

   Front bay to back bay(1-->2 and 2-->1)

   Back bay to front bay (1-->2 and 2-->1)

   Back bay to back bay (1-->2 and 2-->1)

(I didn't test absolutely every single possible combination, just like 5 or 6 variations)

Each time I got some errors.  (Around 11 I think, always the same number except one time, there were about 15 errors).

When I used the Win10 'drag-paste', in the same dock, the files copied with no error.

So, if the dock is the problem, I can copy without issue using drag-drop, and also I can copy to another dock with no issue.

[jaso...@gmail.com]

(Just to clarify- among my 6 or so tests-

Using Fast Copy- 

Copying from one dock to another dock gave no errors.

Copying from one bay to another bay, within one dock, always gave errors.  This happened with both docks.

Using drag - drop

Copying from one bay to another bay, within one dock, gave no errors.

Two source drives, two destination drives.  (Again, I didn't test every possible combination of source/destination drive and front/back bays of two docks.  But I did a pretty clarifying survey of 6 or so variations.)

[SHIROUZU Hiroaki]

All HDD/SSD devices must support Windows File APIs.

Windows File APIs have some options that are direct I/O, async I/O or etc.

I think your device doesn't support some options that should be supported.

I think your device have been checked only for the subset of Windows File APIs that are used by Explorer.

So, I think it is your device's problem.

[jaso...@gmail.com]

Ok, probably that's the case.  Was just letting you know.  Both docks do have a "clone" function that operates outside of a PC.  Maybe that plays a role.  At any rate, it sounds like I can still make copies then, just not using Fast Copy. 

Thanks!