Closed enormlllar closed 7 years ago
Can you send us the fixity manifests (history), reports and debug logs for initial scans and the followup scans that produce this issue? Also, is it possible to try running Fixity on smaller groupings of files to narrow things down and determine if it is particular files that are triggering the issue? You can send things to chris@avpreserve.com. Thanks.
Maybe! But we will certainly have to redact some of the content - leaving dummy file paths/names, for example. Do you think they'll still be useful at that point? Meanwhile, sure, we can run it on a subset of files but should that succeed I'm not going to be super jazzed about then doing another and another and another subset in an attempt to isolate some problem file(s). There are thousands and thousands. I'd like to be able to isolate this w/ extant data (logs etc.)
Ok, well the more you can share and do, the more likely it is that we'll be able to identify and fix the issue.
enormlllar, can you send me an email and I'll send an update for you to test out?
Thanks,
Chris
Please download and try this version. It has a few updates that may solve the problem and more extensive logging in case the issue remains in order to help troubleshooting. https://drive.google.com/file/d/0Bz35MbY5VMhOb3d6U2REVUNVVzQ/view?usp=sharing
Chris, I would love to but (yes, I know I'm annoying)...my organization blocks all traffic to Google Drive, DropBox, etc. But if this is a version that reflects the commit from ~17 days ago (this one), I can just try to compile this myself.
You can use this link instead - https://www.avpreserve.com/wp-content/uploads/2015/08/Fixity_Win_Test.zip
@enormlllar , were you ever able to test this?
My archivist reports she has been in contact w/ you offline (well, email), and that the new version "ran for about 3 days and then ended with a Microsoft Visual C++ Runtime Error...No report file was generated." Error was "Runtime Error!" then the full path to the Fixity.exe, then "This application has requested the Runtime to terminate it in an unusual way...."
Ok, thanks for the feedback. We will look into it and see what we can find. Will report back.
Hello. I am having the same issue that enormlllar is describing above. Should I try the alternate version: https://www.avpreserve.com/wp-content/uploads/2015/08/Fixity_Win_Test.zip or are there news on this topic? I am happy to provide any of the files generated by Fixity. Thanks.
@LorenzoHCL and @enormlllar does this issue persist or was it solved?
Sorry, too long ago. I don’t know/remember. I ended up working around the problem.
@enormlllar and I never figured out a workaround for this issue and had to stop using the application. @LorenzoHCL, if you can share how you got around this, we would appreciate it.
I am frightfully sorry but no, I can't (failing memory and lack of documentation are the culprits).
I'm seeing an issue in both 0.4 and 0.5 (on Windows) where the {{details}} variable block from the report template is not being replaced in the actual resulting report. i.e. the summary values are all there (first 10 lines) and then it's just "{{details}}" verbatim. It maybe corresponds to this error in the debug.log:
DEBUG:root:error_type::<type 'exceptions.UnicodeEncodeError'>
...but that error appears elsewhere in the log in a place that does not seem to correspond to report failure. Worse, the phenomenon is intermittent. Specifically, it feels a little like the issue is occurring because of files that either exist or no longer exist since a previous run (that is, a file that is supposed to be echoing into the {{details}} block). Additionally, it appears everything else about the scan seems to have completed cleanly (i.e. it does appear all of the records that should be in Fixity.db are there and merely the {{details}} report block is choking). I'm hoping perhaps this is enough detail to trigger an idea about what might be happening?