Filebot's renaming of files is causing CrashPlan to fail

Support for Windows users
Post Reply
mitalis
Posts: 2
Joined: 21 Mar 2016, 23:10

Filebot's renaming of files is causing CrashPlan to fail

Post by mitalis »

Hello,

Just wanted to give some info upfront:

Running Windows 10 (version 1511 build 10586.164)
Running Filebot GUI 4.6.1 (Windows Installer)

For some peculiar reason, whenever I rename a media file using Filebot, it is causing my backup program CrashPlan to fail. Upon viewing the logs I see the following:

Code: Select all

STACKTRACE:: com.code42.exception.DebugException: BQ:: Caught unexpected exception...closing session! - worker=TodoWorker@1020339338[ threadName = BQTodoWkr-42, stopped = false, running = true, thread.isDaemon = false, thread.isAlive = true, thread = Thread[W1768140189_BQTodoWkr-42,5,main]], java.nio.file.InvalidPathException: Illegal char <:> at index 70: [b]I:\TV Shows\Daredevil\Season 02\Marvel's Daredevil - S02E01 - Bang.mp4:net.filebot.filename[/b]; BC[639831608029350502>42, sameOwner=f, backupConnected=t, authorized=t, usingForBackup=t, backupReady=t, backingUp=t, validating=f, closing=f, keepBlockState=0, con=2016-03-21T07:41:54:150, val=2016-03-21T07:43:48:587, readyCheckTime=2016-03-21T07:41:54:150, MM[BT 639831608029350502>42: openCount=3, initialized = true, dataFiles.open = true, C:\ProgramData\CrashPlan\cache\42], session=Session[id=734546298784986592, closed=false, isAcceptor=false, remoteIdentity=ENDPOINT, completedAuth=true, lat=2016-03-21T07:45:23:604, lrt=2016-03-21T07:45:23:604, lwt=2016-03-21T07:45:23:543, #pending=0, enqueued=false, local=192.168.10.102:53809, remote=162.222.41.50:443, usingProtoHeaders=true, usingEncryptedHeaders=true, WAN], syncHandler=ClientSyncHandler@884307270[ timestamp=0, txValid=false, bmfValid=false, propsValid=false, pathsValid=false, throttler=930/1000], hosted=t, hostedCloud=t, replacing=f, selectedForBackup=t, selectedForRestore=f, validationNeeded=f, backupUsageTime=2016-03-21T07:43:48:757, restoreControl=RestoreReceiveControl@1272583710[ , hasRestoreEnv=false, hasRestoreJob=false ], cacheMaintenanceState=null, BackupQueue[639831608029350502>42, running=t, #tasks=0, sets=[BackupFileTodoSet[backupSetId=1, guid=42, doneLoadingFiles=t, doneLoadingTasks=f, FileTodoSet@811225132[ path = C:\ProgramData\CrashPlan\cache\cpft1_42, closed = false, dataSize = 5943, headerSize = 0], numTodos = 2, numBytes = 1116586867]]], env=BackupEnv[envTime = 1458571428759, near = false, todoSharedMemory = SharedMemory[b.length = 2359296, allocIndex = -1, freeIndex = 1253, closed = false, waitingAllocLength = 0], taskSharedMemory = SharedMemory[b.length = 2359296, allocIndex = -1, freeIndex = 1767, closed = false, waitingAllocLength = 0]], TodoWorker@1020339338[ threadName = BQTodoWkr-42, stopped = false, running = true, thread.isDaemon = false, thread.isAlive = true, thread = Thread[W1768140189_BQTodoWkr-42,5,main]], TaskWorker@1186332471[ threadName = BQTaskWrk-42, stopped = false, running = true, thread.isDaemon = false, thread.isAlive = true, thread = Thread[W209241969_BQTaskWrk-42,5,main]]] ]
	at com.code42.backup.save.BackupQueue.handleWorkerException(BackupQueue.java:1958)
	at com.code42.backup.save.BackupQueue.access$1000(BackupQueue.java:97)
	at com.code42.backup.save.BackupQueue$TodoWorker.handleException(BackupQueue.java:1828)
	at com.code42.utils.AWorker.run(AWorker.java:150)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 70: [b]I:\TV Shows\Daredevil\Season 02\Marvel's Daredevil - S02E01 - Bang.mp4:net.filebot.filename[/b]
	at sun.nio.fs.WindowsPathParser.normalize(Unknown Source)
	at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
	at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
	at sun.nio.fs.WindowsPath.parse(Unknown Source)
	at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
	at java.io.File.toPath(Unknown Source)
	at com.code42.io.FileUtility.getSafePath(FileUtility.java:653)
	at com.code42.io.FileUtility.getSafePath(FileUtility.java:637)
	at com.code42.io.path.FileId.getFileId(FileId.java:139)
	at com.code42.backup.save.BackupQueue.addResourceFileTodos(BackupQueue.java:1135)
	at com.code42.backup.save.BackupQueue.processTodo(BackupQueue.java:931)
	at com.code42.backup.save.BackupQueue.access$800(BackupQueue.java:97)
	at com.code42.backup.save.BackupQueue$TodoWorker.doWork(BackupQueue.java:1811)
	at com.code42.utils.AWorker.run(AWorker.java:148)
	... 1 more
It would seem for whatever reason, CrashPlan is failing to upload the file due to the :net.filebot.filename being added to the end of the file. Upon looking at the file via Explorer, I do not see this anywhere in the file, so I'm unsure how (or why) CrashPlan sees this. All I know is that it's interpreting the file path in it's entirety to something that doesn't exist.

If I do a manual rename of the file via Windows Explorer, CrashPlan will upload the file no problem. Is there a way to prevent that :net.filebot.filename from being applied to the file upon renaming using the Windows GUI client? If so how do I set this?

Thank you.

- Mitalis
User avatar
rednoah
The Source
Posts: 22998
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Filebot's renaming of files is causing CrashPlan to fail

Post by rednoah »

Have you read this?
https://blog.jmwhite.co.uk/2016/03/19/c ... ttributes/

When FileBot processes files, it will store some metadata in Extended Attributes:
https://en.wikipedia.org/wiki/NTFS#Alte ... _.28ADS.29

You can disable xattr via the *.ini config files.

Please report this bug to the CrashPlan developers. They've probably rolled their own low-level filesystem API, that apparently doesn't deal with ADS correctly. They need to fix their code. ;)
:idea: Please read the FAQ and How to Request Help.
mitalis
Posts: 2
Joined: 21 Mar 2016, 23:10

Re: Filebot's renaming of files is causing CrashPlan to fail

Post by mitalis »

rednoah wrote:Have you read this?
https://blog.jmwhite.co.uk/2016/03/19/c ... ttributes/

When FileBot processes files, it will store some metadata in Extended Attributes:
https://en.wikipedia.org/wiki/NTFS#Alte ... _.28ADS.29

You can disable xattr via the *.ini config files.

Please report this bug to the CrashPlan developers. They've probably rolled their own low-level filesystem API, that apparently doesn't deal with ADS correctly. They need to fix their code. ;)
Thank you so much for this! I found the thread that listed the command lines, but I didn't know for the GUI client you could make the changes with the .ini files. Much appreciated!
Post Reply