sausages
-
Posts
16 -
Joined
-
Last visited
Posts posted by sausages
-
-
New update: now at 67% (on an 8TB drive) and the web UI has been showing files being moved as well. So there is hope yet.
-
3 hours ago, steffenmand said:
1306 doesnt show any files being moved though like 1305... so dont know if it works or not :-P
Yea, that's basically my issue at this point - other than the percentage increasing, there's no evidence anything is actually happening anymore
-
5 minutes ago, srcrist said:
Just a note for those of you concerned with a lack of drive activity via the web interface: I don't believe Google reports file *movement* in the activity panel. Only file creation and modification. If the file is simply moved from folder A to folder B, it shouldn't show up. To confirm that the migration is working correctly, I would note the most recent directory structure and compare it some time later and see if new folders have been created or files have been moved to the folders that exist.
Theoretically, this migration should produce little, if any, "activity" in the web interface activity panel.
This is not correct, the web UI shows file movement.
-
Well I went to bed leaving the process running - last I checked, it showed it was about 15% done. Woke up this morning, and now it indicates it is 2% done... Not going to lie, this seems very glitchy.
EDIT: I checked the service log and noticed that it was throwing up the "Server is unavailable" error. I upgraded to 1306 which did away with these errors, and the progress counter is increasing as well. However, the Google Drive web interface doesn't show any file activity, and the service log doesn't show anything happening either (verbose tracing is on). I'm really disappointed in how poorly this migration seems to have been implemented, and concerned my drive is toast somehow. -
Well, I've started the process on my 8tb drive. Now at 2.35%. Hopefully this doesn't wreck the drive, though it seems no one here has yet reported a successful and problem-free conversion??
-
On 2018-02-13 at 11:25 AM, Christopher (Drashna) said:
Does this still occur on 1.0.2.975?
http://dl.covecube.com/CloudDriveWindows/rc/download/StableBit.CloudDrive_1.0.2.975_x64_Release.exe
Unfortunately yes - it occurred after my most recent reboot while using 975.
-
-
I've submitted the drive tracing and troubleshooter logs, but wanted to mention that this is still consistently happening. I'm thankful I do not have a bandwidth cap and have fast upload speeds, otherwise the software would be completely unusable.
EDIT: Furthermore, another quirk I've noticed is that attaching the drive often results in extraordinarily high memory usage (as seen in the attached screenshot) that momentarily cripples the computer. Is such behaviour expected?
-
Hello,
I'm having an issue where at least 50% of the time (if not more) when I restart my computer, CloudDrive seems to not shutdown properly and initiates a recovery upon startup. Looking at my Windows event log from the most recent occurrence, I found this:
"The StableBit CloudDrive Shutdown Service service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service."
I've attached a copy of the event file in case that helps. I'm running Windows 7 x64 and CloudDrive 1.0.2.964. Thanks!
-
The high MB is due to the NTFS storing data in memory about each file. Due to the high volume of files due to the chunk system, it will over time use more and more memory as files get indexed. It is due to the way NTFS works and not something to do with Cloud Drive.
Try adding a couple of million files to your own drive and see the same result over time
I don't understand how you conclude this. As I've mentioned, previous builds of CloudDrive do not present this issue, and I'm fairly sure they utilize the same chunk system.
To be clear, this isn't just a theoretical issue either. At least on my computer, the OS becomes entirely unusable once all memory is exhausted.
-
Hm interesting. I've downgraded back to 730 for now, seeing under 200mb while uploading to ACD.
-
-
Thanks for the response.
This can lead to data corruption.
That's the question though, what data is likely to be corrupted? Put it another way: if i'm uploading a batch of photos and my cache drive completely fails mid way, is it possible that photos I have already uploaded years ago sitting on the cloud server can be corrupted as well (i.e. the entire cloud drive and *all* cloud data is now lost)? I understand the rationale for having a cache and for the data being actively written to be lost in the event the cache drive fails, but data that has completely been uploaded should not be at risk - otherwise, what is the point of storing data in the cloud at all?
-
The problem comes in if you had a lot of data left to upload. In this case, you may end up with corrupted data.
Could you elaborate on this? If the hard disk I'm writing/uploading files from dies with data left over on the cache, the data already stored on the cloud may be corrupted? I'm just trying to gauge how secure data that's been written to the cloud is in the event of hardware failure.
-
I'm getting the exact same error, despite having the Security Profile along with the Web Settings pages set up correctly
Google Drive: The limit for this folder's number of children (files and folders) has been exceeded
in General
Posted
Upgraded to this version and my drive instantly mounted. If I understand the logs correctly, the new version simply doesn't bother moving chunks if the drive is under the 490k limit? I'm assuming upgrading part way through the prior version moving the files hasn't broken anything but I am entirely not sure.