Since version 0.05 I get the following error immedately after issuing disparity create:
Scanning F:\BaseCamp...Fatal error: Could not find a part of the path 'F:\BaseCamp\Movies\Michael Clayton'.
Aborting.
0.04 seems to work OK, gets passed this poing just fine.
Any ideas?
The difference between 0.04 and 0.05 is just that 0.04 ignored errors during the initial directory traversal and just skipped the directory, while 0.05 reports the error and stops. So 0.04 was almost certainly encountering the same problem, it just wasn't reporting it.
So now the question is, why the problem with this one particular directory? Is there anything you can think of about it that is unusual? Possibly a protections issue of some sort (e.g. user access control)? Or perhaps a bad shortcut? Anything like that?
This is probably a bug in disParity: The folder-name "Michael Clayton " ended in a white-space (probably a SPACE). My guess is that you trim the folder-path somewhere in your code before you re-use it. When I removed the trailing white-space everything worked fine.
Also I have an (IMHO important) feature request: add a switch allowing disparity to continue even if it encounters errors (issue a WARN entry in the log-file). On large disks with a lot of data you're almost bound to encounter a file/folder that can't be read (locked, insufficient privileges etc). For a tool like disparity which for the time being is "best-effort" parity backup this is reasonable behaviour.
Other than that - great effort - disParity is exactly what's needed for an "amateurs" media library. I sleep a lot better now.
Very strange. DisParity doesn't trim whitespace off of folder names deliberately. In fact I tried to repro this and I cannot, Windows will not let me create a folder name with extra spaces on the end. Windows trims them off automatically when I try to commit the new folder name. So maybe they weren't spaces, but some other odd whitespace character. I'll have to keep an eye out on this. If you can think of any clues as to what character that might have been, or how it got there so I can try to repro here, that would be really helpful.
Rather than add an option, I think it makes more sense to just make warn-and-continue the normal mode of operation during a create. I'll make that change in the next update.
... then you probably want to add an option for halt-on-error - some people will definatly request it.
You must log in to post.