Copy files to drive, delete, CloudDrive is still trying to upload them?

[dannybuoy]

Currently trialling 1.0.0.723. I created 2TB drive on a trial unlimited Google Drive account tried to copy a >300GB music library to it. However it kept stopping due to I/O errors, believing there to be a problem with the cache disk:

 

I/O error

Cloud drive (H:\) - Google Drive is having trouble writing to the local disk DISK4 (C:\MNT\DISK4\).

This error has occurred 46,138 times.

Your local disk may be failing. Detach the cloud drive from this disk.

Continuing to get this error can affect the data integrity of your cloud drive.

 

Stablebit Scanner is not reporting any issues with the drive and I can copy the same set of files to the cache drive no problem. 

 

So then I destroyed the drive and started again, choosing a different cache disk this time. The files copied over fine this time, but when I returned to it I saw that hardly anything had been uploaded to the drive and upload had stopped. The error this time read:

 

I/O error

Cloud drive (H:\) - Google Drive is having trouble uploading data to Google Drive in a timely manner.

Error: Thread was being aborted.

This error has occurred 477 times.

Ths error can be caused by having insufficient bandwidth or bandwidth throttling.

Your data will be cached locally if this persists.

 

I have about 15Mbps upload and 45Mbps download - checked the logs and it's full of 'User Rate Limit Exceeded' errors. Anyone know if this is a rate limit they apply to trial accounts that improve if purchased?!

 

After a reboot I saw some upload activity happen for a while before stopping again and the same error shown as above.

 

I I then deleted the files from the drive and copied over 2 or 3 GB of video files. Now even after a few reboots, the UI is still saying there is around 300GB to upload. I've tried wiping the cache to no avail. Is this expected behaviour - that once a file is queued for upload it stays in that queue even if deleted from the drive?

 

Right now I can't even detach the drive as it still believes it has 300GB to upload, and it's unable to upload them anywhere, so I would right now be forced to stop the CloudDrive service and delete the CloudDrive folder on my Google Drive if I wanted to destroy this disk.

[Christopher (Drashna)]

The "User Rate Limit Exceeded" error is the issue here. 

 

When is the most recent time that this has occurred? (specifically, has it happened in the last day or two?)

[dannybuoy]

It was happening last night until this afternoon when I had to manually destroy the drive. Upload eventually resumed and no more errors were appearing in the UI, but I didn't want to wait for it to upload 300GB of deleted files when my cloud drive volume was in fact empty!

[Christopher (Drashna)]

Okay, thank you for leting me know.

 

As for the "to upload", even if you've deleted the data... it's still mostly there.  This is because NTFS doesn't remove the actual contents, just the pointers to the files. Meaning that you can run data recovery tools on the CloudDrive disks, just like a normal, physical disk. 

[dannybuoy]

Ah, I get it now!

 

If I test this again I will try running sdelete on the drive to see what happens... but if that tries to download every chunk in order to analyse the disk, perhaps some other utility that can securely delete files by zeroing the unused bits would be appropriate.

 

Personally I would prefer that CloudDrive had an option to ignore chunks that aren't referenced by an actual file, if that were architecturally possible.

[Christopher (Drashna)]

Personally I would prefer that CloudDrive had an option to ignore chunks that aren't referenced by an actual file, if that were architecturally possible.

 

Actually, we *could* do that.  StableBit Scanner has a custom NTFS parser that actually does this, specifically. That's how the file recovery feature works. 

 

The problem is that it's time and resource intensive, and would have to read a BUNCH of the disk. Essentially negating any gain that you'd gain by using it (which is likely *why* alex didn't include this sort of functionality).