After OS5 installation I tried to copy my existing files on a prior My Cloud device to my new My Cloud EX2 Ultra. The prior total storage used was 1.19 TB but on the EX2 is only 704 GB. Upon further exploration I noticed that File Sizes were the same in both locations but the prior My Cloud had a larger File On Disk size than the File Size for each file (as expected) and the new EX2 had the same size for both (which can’t possibly be true). So…
#1: How can I easily check that all my files copied over successfully without having to look at each and every file (or folder).
#2: Isn’t this an error in OS5 if it’s reporting to Windows File Explorer the same size for both File Size and File Size on Disk? Is there a way to fix this?
I was hoping for a more helpful answer rather than the facetious answer I’m given here.
#1: I have had problems with Windows 10 drag and drop copy in the past and it’s well documented to have issues with very long path or file names. However, I don’t know of a better way to accurately copy files to a new storage location. So, I check the disk properties after the Copy to see how much storage is used on disk following the copy compared to the storage used by the source of the files. This should work if the File Size on Disk is properly accounted for by the server.
#2: Windows File Explorer accurately reports these stats for all other storage I’m using or that I’ve heard being used by others. If the Storage Used / File Size On Disk is being inaccurately reported, that has to be a WD problem, not a Microsoft problem. You respond as if you work for WD or have to defend them somehow. The WD drive is reporting to Windows it’s Storage Used and Storage Free. File Explorer just displays the data it is given. The WD drive is reporting File Size = File Size on Disk. This is not possible with current block data storage techniques so WD must be incorrectly reporting it’s Storage Used and Storage Free numbers since WD is reporting the Storage Used = File Size (incorrect) rather than the Storage Used = File Size on Disk (correct). Unless WD has come up with a new innovative storage technology that doesn’t require assignment of data to memory blocks which I sincerely doubt.
I am hoping I can get a less sarcastic and more helpful response from someone. Has anyone else experienced this issue when copying data from an existing NAS to the WD EX2 Ultra? If so, how did you verify that all the data was completely and accurately copied?
It must be early. . . I can’t quite comprehend these answers either.
A few quick thoughts;
-
I think you really need a file comparison program to do what you are asking. I use something called “folder match”.
-
I would view the “file properties” function a bit askance - as in the best case it only tells you # of files and total size? This might get a bit complicated if the folders you are comparing are on different drives with different block sizes. (which . . . .considering that the MyClouds format as Linux disks . . . EXT4?. . . and not Windows NTFS. . .)
-
Look. . if you file names are longer than 256 characters. . . well. . . I think you need to make some modifications to your path names Maybe shorten some actual file names or directory names. I have had some problems with files in the past. . . and did some pruning of the problem children. I have had single character file names before. . .
-
I also use drag and drop as my preferred transfer method. Never trusted other backup programs since my corporate IT used a disk transfer program that successfully copied a full 1/3 of my data from “old” to “new” pc. . . . . Thank GOODNESS I made a 100% backup of user data (using a forbidden HDD) prior to handing over my machine. . . .I guess this is why they now have everyone use OneDrive. . . .
Thanks NAS_user. That is what I was looking for. I purchased FolderMatch and it did exactly what I was looking for. I only had a few files that didn’t copy right and needed to be recopied. Now it’s all fixed.
I did some research on my own as well and I agree that the difference in storage used between source and destination is that the file allocation / cluster size is much smaller on the destination than the source leading the destination to store the data more efficiently and take up less space.
Anyway, problem solved. Thank you very much!