Rename Windows 10 - very slow (because Acronis True Image)

[rednoah]

Timestamp 1: ( 3 rows) was a move command inside powershell -> same result, about 24 seconds.
Timestamp 2: ( 2 rows) was instantly moving the file back to it`s origin place via Windows STRG-X -> STRG-V
Timestamp 3: ( 1 row) was a 2nd move inside powershell which is carried out in a second...

Very mysterious indeed. I can only assume it's a SMB file system driver issue. I would guess that the "read" in the SMB log doesn't necessarily indicate a complete file read, but perhaps only a partial read that Windows does for some reason. But I wouldn't know how to further debug Windows internals.


Unfortunately, I'm fairly sure that the issue cannot be solved within FileBot, especially since the issue fixes itself entirely on a new pristine Windows install.


We could confirm this via Groovy Pad and writing code that does nothing but a rename operation. If this takes a long time, then there's nothing we could possibly do differently as far as FileBot code is concerned:

Code: Select all

def a = /X:\test\a.mkv/ as File
def b = /X:\test\b.mkv/ as File

def t = System.currentTimeMillis()
java.nio.file.Files.move(a.toPath(), b.toPath())
println(System.currentTimeMillis() - t)

[gohakn]

My Filesize was 1,5 GB and the result until it finished in GroovyPad is 14257.

As long as it was running i could see this 100MB/s DL Peak inside my network Monitor


Could it be a result of "to many" Versions of Java i`ve installed before?

[rednoah]

GroovyPad is 14257.

14 seconds for a single Files.move() call definitely isn't right. Unfortunately, we have essentially confirmed that we cannot possibly solve or workaround the issue from FileBot code, because we either perform a move operation or we don't.


FileBot does not use any system Java that you may or may not have installed. Java 7 and 8 are 11 and 9 years old respectively. I strongly recommend uninstalling all of them. That said, uninstalling all of them has no effect on FileBot.

[rednoah]

I've update the unit test code with an interesting addition, setting the ATOMIC_MOVE should explicitly force an instant-move operation, or fail, so that would be an interesting test case, see if that works, or if it gives us a new interesting error message with clues:

Code: Select all

def a = /X:\test\a.mkv/ as File
def b = /X:\test\b.mkv/ as File

def t = System.currentTimeMillis()

Files.move(a.toPath(), b.toPath(), StandardCopyOption.ATOMIC_MOVE)

println(System.currentTimeMillis() - t)

[gohakn]

File is moved without crash but took 15396.

I`m also trying to find out the difference betwenn my two PCs.
I found a MIcrosoft Page with knowledge about SMB Versions and no I`m checking if there`s a difference although I never changed something of the internals..
https://learn.microsoft.com/de-de/windo ... abs=server

[gohakn]

@Rednoah

Tok Tok,
it`s me back after 2 month of reading & posting through different Windows Forums, trying differnet things, and now my problem is solved.

Short Version...

On my Computer with the strange behaviour of reading every File which should only be renamed ther was a tool installed called "Acronis True Image".
This tool ( i found a hint in the Task Manager -> Ressource Monitor ) was reading/caching every File in the compled Filesize befor the Rename Command from Filebot was carried out, lasting in this long delays.
The Process's Name in the Resource Monitor is "C:\System Volume Information\FileProtector\FileStorage\", just in case somebody reads this and is encountering the same problems.
After uninstalling the Acronis Tool, FileBot is doing it`s Job within seconds.

[rednoah]

Thank you for reporting back! I could only ever guess at "software that interferes with Windows internals" so it's really good to know that Acronis True Image is the culprit in this case.