Closed rosyth closed 4 years ago
I've seen a similar state inconsistency bug in one of my machines when using the -dev build. Still need to chase it down.
I see now that the use of absolute path or relative does not prevent the bug. A different run on a different mount caused the failure with a relative path given. The release version 1.7 performs ok every time I've seen a failure with 2.0. I wish you luck tracking down the bug.
The most recent changes in master (2.0-dev) should fix this, let me know if not.
This is a bit strange, exactly the same root path given to --path but in different ways. The local relative reference works with no problem, the full path passed from mount point fails. The files that are referenced by the error (anonymised) run in hash mode with the full path returns a hash with no problem. Is this a problem with the long path string? The anonymised path is exactly the same length as the original. There are no special chars. Also, the release version (1.7) has no issues. See the attached file for the output for each of the dupd variant runs. dupd_error.txt
I've created 2 compiles, dupd_latest (2.0-dev) and dupd_release (1.7). You can see that only the latest has a problem.