Advertisement

Alternating between Synchronizing & Connecting to Destination on WD MyCloud

Home Forums Crashplan on Other NAS systems Alternating between Synchronizing & Connecting to Destination on WD MyCloud

  • This topic has 1 reply, 2 voices, and was last updated 8 months ago by an an.
Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #895

    Cowboys630
    Participant

    First, great forum!

    I’m not sure if anyone here uses a WD MyCloud.  One of these days I plan on upgrading, but for now it’ll do.  I’ve been running CrashPlan on my MacBook Pro for a year or so probably, with no issues.  I’ve been very pleased since it didn’t get corrupted and make me start over every month or so, like Time Machine.  🙂

    Recently, it got stuck ‘Verifying files (deep)’ at about 5 % for like a week.  I know it can take a long time, but it wasn’t really making any progress at all.  I contacted Support, but haven’t gotten really far.  Since then, I’ve tried all sorts of things.  Clearing cache, uninstalling, reinstalling, you name it.  Now I’ve actually got a different issue.

    Whenever I point it to my existing backup, it connects fine, starts the scan immediately and starts synchronizing.  It will synchronize to 20.9% every time, then switches to trying to connect to the destination for a bit, then back to synchronizing.  I don’t think it’s just a matter of the drive disconnecting.  It won’t make any more progress, if anything the To-do number will grow.  It keeps going like this forever.  I found the KB on this site for Fixes for CrashPlan randomly restarting or not backing up and tried the steps to no avail.  I also read on CrashPlan’s site that moving the archive to a new location and then pointing to it can solve the issue.  I didn’t have enough room to copy the archive (1.7TB) so I changed the name of the Share it’s located in on the drive, and went through the process or removing the existing archive and pointing it to the new one.  It pretty much did the same thing.  It has gone into a ‘Verifying blocks (deep)’ mode a couple of times, but has ended up going back.

    Digging in the System.log there’s actually a lot of this error, which seems like it’s hitting something in the archive that it doesn’t like (around the 20.9% mark I suppose) and then starts bombing:

    [01.25.17 20:50:13.630 WARN W-sId…3189 com.code42.backup.BackupEntityV1] BC[729663389825078976>779527718205679701:: Exception receiving backup file histories! …closing, e=java.lang.NegativeArraySizeException; BC[729663389825078976>779527718205679701, DIRECT CHILD, sameOwner=t, backupConnected=t, authorized=t, usingForBackup=t, backupReady=t, backingUp=f, validating=t, closing=f, keepBlockState=0, con=2017-01-25T20:50:05:198, val=2017-01-25T20:50:13:381, readyCheckTime=2017-01-25T20:50:05:198, MM[BT 729663389825078976>779527718205679701: openCount=1, initialized = true, dataFiles.open = true, /Library/Caches/CrashPlan/779527718205679701], session=779549658492463189, hosted=f, replacing=t, selectedForBackup=t, selectedForRestore=f, validationNeeded=f, backupUsageTime=2017-01-25T20:50:05:202, [email protected][ , hasRestoreEnv=false, hasRestoreJob=false ], cacheMaintenanceState=null, BackupQueue[729663389825078976>779527718205679701, running=f, #tasks=0, sets=[BackupFileTodoSet[backupSetId=1, guid=779527718205679701, doneLoadingFiles=t, doneLoadingTasks=f, [email protected][ path = /Library/Caches/CrashPlan/cpft1_779527718205679701, closed = false, dataSize = 258190837, headerSize = 0], numTodos = 1394836, numBytes = 346709496796]]], env=null, [email protected][ threadName = BQTodoWkr-779527718205679701, stopped = true], [email protected][ threadName = BQTaskWrk-779527718205679701, stopped = true]] ]; , com.code42.exception.DebugException: BC[729663389825078976>779527718205679701:: Exception receiving backup file histories! …closing, e=java.lang.NegativeArraySizeException; BC[729663389825078976>779527718205679701, DIRECT CHILD, sameOwner=t, backupConnected=t, authorized=t, usingForBackup=t, backupReady=t, backingUp=f, validating=t, closing=f, keepBlockState=0, con=2017-01-25T20:50:05:198, val=2017-01-25T20:50:13:381, readyCheckTime=2017-01-25T20:50:05:198, MM[BT 729663389825078976>779527718205679701: openCount=1, initialized = true, dataFiles.open = true, /Library/Caches/CrashPlan/779527718205679701], session=779549658492463189, hosted=f, replacing=t, selectedForBackup=t, selectedForRestore=f, validationNeeded=f, backupUsageTime=2017-01-25T20:50:05:202, [email protected][ , hasRestoreEnv=false, hasRestoreJob=false ], cacheMaintenanceState=null, BackupQueue[729663389825078976>779527718205679701, running=f, #tasks=0, sets=[BackupFileTodoSet[backupSetId=1, guid=779527718205679701, doneLoadingFiles=t, doneLoadingTasks=f, [email protected][ path = /Library/Caches/CrashPlan/cpft1_779527718205679701, closed = false, dataSize = 258190837, headerSize = 0], numTodos = 1394836, numBytes = 346709496796]]], env=null, [email protected][ threadName = BQTodoWkr-779527718205679701, stopped = true], [email protected][ threadName = BQTaskWrk-779527718205679701, stopped = true]] ];
    STACKTRACE:: com.code42.exception.DebugException: BC[729663389825078976>779527718205679701:: Exception receiving backup file histories! …closing, e=java.lang.NegativeArraySizeException; BC[729663389825078976>779527718205679701, DIRECT CHILD, sameOwner=t, backupConnected=t, authorized=t, usingForBackup=t, backupReady=t, backingUp=f, validating=t, closing=f, keepBlockState=0, con=2017-01-25T20:50:05:198, val=2017-01-25T20:50:13:381, readyCheckTime=2017-01-25T20:50:05:198, MM[BT 729663389825078976>779527718205679701: openCount=1, initialized = true, dataFiles.open = true, /Library/Caches/CrashPlan/779527718205679701], session=779549658492463189, hosted=f, replacing=t, selectedForBackup=t, selectedForRestore=f, validationNeeded=f, backupUsageTime=2017-01-25T20:50:05:202, [email protected][ , hasRestoreEnv=false, hasRestoreJob=false ], cacheMaintenanceState=null, BackupQueue[729663389825078976>779527718205679701, running=f, #tasks=0, sets=[BackupFileTodoSet[backupSetId=1, guid=779527718205679701, doneLoadingFiles=t, doneLoadingTasks=f, [email protected][ path = /Library/Caches/CrashPlan/cpft1_779527718205679701, closed = false, dataSize = 258190837, headerSize = 0], numTodos = 1394836, numBytes = 346709496796]]], env=null, [email protected][ threadName = BQTodoWkr-779527718205679701, stopped = true], [email protected][ threadName = BQTaskWrk-779527718205679701, stopped = true]] ];
    at com.code42.backup.BackupEntityV1.logAndClose(BackupEntityV1.java:733)
    at com.code42.backup.BackupEntityV1.logAndClose(BackupEntityV1.java:700)
    at com.code42.backup.manifest.SyncHandler.logAndClose(SyncHandler.java:182)
    at com.code42.backup.manifest.ClientSyncHandler.receiveMessage(ClientSyncHandler.java:1221)
    at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.code42.messaging.MessageReceiverProxy.receiveMessage(MessageReceiverProxy.java:153)
    at com.code42.messaging.SessionImpl.receiveMessage(SessionImpl.java:479)
    at com.code42.messaging.direct.DirectMessageQueue.receiveMessages(DirectMessageQueue.java:129)
    at com.code42.messaging.direct.DirectMessageQueue.access$000(DirectMessageQueue.java:22)
    at com.code42.messaging.direct.DirectMessageQueue$ReceiveWorker.run(DirectMessageQueue.java:168)
    Caused by: java.lang.NegativeArraySizeException
    at com.code42.backup.manifest.SecureBackupFile.<init>(SecureBackupFile.java:86)
    at com.code42.backup.manifest.BackupFileHistory.<init>(BackupFileHistory.java:33)
    at com.code42.backup.manifest.ClientSyncHandler.receiveMessage(ClientSyncHandler.java:1181)
    … 8 more

    I’ve searched on NegativeArraySizeExceptions, but haven’t found anything that I could put to use, but that may just be me not understanding it fully.

    If anyone has any advice, I’d greatly appreciate it.

    Thanks in advance!

    #896
    an
    an
    Keymaster

    Hi,

    I really can’t say but I would guess that it’s more of a Java issue than anything… As CrashPlan for macOS comes bundled in, have you tried either upgrading or using an earlier version of CrashPlan?

     

Advertisement
Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.
https://i2.wp.com/crashplanbackup.com/wp-content/uploads/2015/11/crashplan-fix.png?fit=512%2C512&ssl=1https://i2.wp.com/crashplanbackup.com/wp-content/uploads/2015/11/crashplan-fix.png?resize=150%2C150&ssl=1Cowboys630Home › Forums › Crashplan on Other NAS systems › Alternating between Synchronizing & Connecting to Destination on WD MyCloud This topic has 1 reply, 2 voices, and was last updated 8 months ago by  an.Viewing 2 posts - 1 through 2 (of 2 total) Author Posts January 26, 2017 at 02:30 #895 Cowboys630Participant First, great...Unofficial Help & Support Forum for CrashPlan, Cloud Backup and Cloud Storage Solutions - Find Help, Support and a Knowledge base

Here's what other Users are reading:

Affiliate Links
Advertisement

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close