1

My WD MyWorldBook is pretty old as you can tell, so I've taken it upon myself to transfer everything to my PC before it inevitably keels over, but when I go to copy everything, Windows gets stuck discovering the size/amount of files, the size just goes up and up and up until 30 minutes later it's sized up to be 650GB and climbing!!! Even though it is absolutely not that big. If I go into a specific folder within the ones I am trying to copy over and attempt to copy it, It works just fine for some reason discoverers files in an instant and copies.

What's going on here? Is the NAS finally corrupted or Is it a windows related thing?

user9100871
  • 11
  • 2
  • If you sign into the NAS's web interface, how full does it report that it is there? Also, install TreeSize on your laptop and do a scan of this network share on the NAS. It will quickly tell you what's taking up all that space. https://customers.jam-software.de/downloadTrial.php?article_no=80 I wouldn't bother with running chkdsk until after checking these two things. – Mr Ethernet Aug 18 '19 at 16:17

2 Answers2

0

I'm assuming that when you mount the drive it shows files and folders, but when you try to copy, it does the slowdown. This could be caused by a number of things, but the simpler solution would be to setup a new folder on the PC in which to copy the files. Then start copying files a few at a time - say 10 folders. If that works, then do another 10. At some point, You will probably come across the file or folder that's causing the problem. Ignore it and continue copying the other files. When you're satisfied all the other files are copied, run checkdisk on the WD and see if it fixes that file. You may find that it is permanently corrupted and unrecoverable.

user76732
  • 633
  • 3
  • 4
  • "run checkdisk on the WD and see if it fixes that file" How do I specifically do this? chkdsk on CMD can't find the file path – user9100871 Aug 18 '19 at 16:11
  • What drive letter is the WD drive? Say it is G as an example, here is the command, "chkdsk G:" (without quotes) this will run chkdsk without any repairs but will still let you know if there are errors on the volume. If it finds errors Then you can run "chkdsk /f G:" which will attempt repairs. Back up critical data before running chkdsk /f – Moab Aug 18 '19 at 16:18
  • The most likely explanation is that there really *is* a lot of data hidden away in a subfolder somewhere in that share. This data could be a few levels deep, perhaps somewhere unexpected. I don't think there's anything corrupted at this stage. I would index the files using TreeSize to see how big the biggest folder is and get a breakdown by size of all of the folders. You can also see how much space *really* is occupied on the NAS by signing into the NAS's web interface. That would give you a number immediately, without even having to wait for a scan. – Mr Ethernet Aug 18 '19 at 16:33
  • "I would index the files using TreeSize to see how big the biggest folder is and get a breakdown by size of all of the folders. You can also see how much space really is occupied on the NAS by signing into the NAS's web interface." I have tried this with WinDirStat and it suffers the exact same problems as explorer, it just eternally discovers more and more files until it's stupendously huge and still stuck at 37% progress. – user9100871 Aug 18 '19 at 16:36
  • This is interesting. What does the NAS's Web UI report as your % disk usage? Checking it this way avoids having to enumerate all the files on the share across the network, so it should give you a number immediately. – Mr Ethernet Aug 18 '19 at 16:40
  • 38% of 4 terrabytes – user9100871 Aug 18 '19 at 16:45
  • Ok great. Well I would personally let WinDirStat index the whole 1.52 TB of data that's on the drive and then come back in a little while to plan my next step! – Mr Ethernet Aug 18 '19 at 16:53
  • I just tried WinDirStat for the first time. Scanning my laptop's entire C drive took 26.5 seconds. The same scan with TreeSize takes just 2.5 seconds. I suspected it would be slower but had no idea the difference would be this pronounced. I strongly advise you to give up on WinDirStat for this and just use TreeSize to enumerate the 1.52 TB on the NAS. I think part of the reason this scan is so slow is because of the inferior tool being used. TreeSize is 10x faster. – Mr Ethernet Aug 18 '19 at 17:20
  • "strongly advise you to give up on WinDirStat for this and just use TreeSize to enumerate the 1.52 TB on the NAS." doing rn – user9100871 Aug 18 '19 at 17:21
  • It turns out others here knew how slow WinDirStat was years ago. https://superuser.com/questions/1069643/is-it-surprising-that-windirstat-takes-a-long-time-to-analyze-8tb-drive The latest stable release is from 2007!! – Mr Ethernet Aug 18 '19 at 17:26
  • 1
    yikes, didn't know there were alternatives until now, TreeSize is astronomically faster and not hanging up so far – user9100871 Aug 18 '19 at 17:30
0

"Even though it is absolutely not that big."

Something really is that big!

"If I go into a specific folder within the ones I am trying to copy over and attempt to copy it, It works just fine for some reason discoverers files in an instant and copies."

That's because you're copying folders that happen to be smaller and/or have fewer files. One or more of the remaining folders contain that 650+ GB of data. It's in there somewhere, most likely hidden in a subfolder that you never suspected.

"What's going on here? Is the NAS finally corrupted or Is it a windows related thing?"

Probably neither. It's a Windows-related issue in as far as Windows Explorer isn't the right tool for copying this much data. If you ran Robocopy, it would start immediately as it doesn't check all of the files first (which is why Robocopy doesn't give you a progress bar but Windows Explorer does... when it eventually starts!)

chkdisk isn't relevant here. The obvious first steps haven't been covered yet.

Forget WinDirStat, it hasn't been updated since 2007 and is about 10x slower than TreeSize.

I don't think there's any data corruption at all, WinDirStat is just extraordinarily slow. Once TreeSize has identified the massive subfolder, you can easily exclude it when copying your files.

Mr Ethernet
  • 4,191
  • 2
  • 16
  • 28