ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Skwire Empire

Release: SFV Ninja (Simple File Verification application)

<< < (15/32) > >>

stefanobrunesci:
Hi, thanks for this program :)

Pretty sure I've found a bug with it when running multiple instances on Win7 64bit. To recreate:-

1. Create a checksum file (I used Md5) for a directory containing a few hundred files of around 20mb each (I'm checking .CR2 image files). Save it in the directory.

2. Open TWO instances of SFVNinja by double-clicking the .Md5 file.

3. Start verifying all files in both instances.

Both instances should report a random selection of "bad" checksums.

If you only run 1 instance of SFVNinja or leave one open but not verifying while you verify with the other, then all files are verified as ok. As soon as two instances are verifying at the same time, spurious "bad" results occur.

The same problem occurs if two or more instances are verifying different directories against different checksum files.

I'm guessing it's some kind of threading issue.

I haven't checked if it also happens if one instance is creating new checksums while a second is verifying a different directory, but I expect it does as that's what I was doing when I first started seeing "bad" checksums. The scenario above was created specifically to test for this bug.

This had me very worried that my files were randomly corrupting themselves in-situ for a while!! :D

Luckily, the workaround (to only run one instance at a time) seems to work, although of course it's less convenient.

I'm using Version 1.1.3 Build 1

Thanks again anyway!


Ciao
Stefano

www.stefanobrunesci.com

skwire:
Hi, thanks for this program :)-stefanobrunesci (September 07, 2012, 08:38 AM)
--- End quote ---

You are welcome and welcome to the DonationCoder site.

2. Open TWO instances of SFVNinja by double-clicking the .Md5 file.
3. Start verifying all files in both instances.
Both instances should report a random selection of "bad" checksums.-stefanobrunesci (September 07, 2012, 08:38 AM)
--- End quote ---

Hmmm...I did some thinking about this and made a small change in the code.  Please redownload the zip and let me know if v1.1.3.2 makes any difference in your tests.  Thank you.


Cornucopiae:
Hi skwire, thanks for the update!

just tested the latest version SFV Ninja v1.1.3.2

Why so slow?
For example, checking 369 files

SFV Ninja v1.1.2 = 00.00.03 min Elapsed time

Release: SFV Ninja (Simple File Verification application)

SFV Ninja v1.1.3.1
SFV Ninja v1.1.3.2 = 00.01.43 min Elapsed time

Release: SFV Ninja (Simple File Verification application)

what do you think?

f0dder:
Hmmm...I did some thinking about this and made a small change in the code.  Please redownload the zip and let me know if v1.1.3.2 makes any difference in your tests.  Thank you.-skwire (September 07, 2012, 03:03 PM)
--- End quote ---
Any hints as to what the issue is (or what you thought it is)? Sounds interesting :)

skwire:
Why so slow?-Cornucopiae (September 08, 2012, 04:37 AM)
--- End quote ---

In AutoHotkey, there are no native hash/checksum commands.  So, you have three options: 1) Use a command line executable, 2) a DLL, or 3) use a function library that somebody has developed.  SFV Ninja uses number one and three.  However, I've found that the function library, while very fast and accurate, has a tendency to crash randomly and I don't know why.  So, I changed SFV Ninja to only use that function when absolutely necessary where before it was using it for smaller files because of its speed.

Any hints as to what the issue is (or what you thought it is)?-f0dder (September 08, 2012, 07:44 AM)
--- End quote ---

So, back to the explanation of SFV Ninja using a command line executable for most of the grunt work.  SFV Ninja creates a temp folder and extracts the necessary files it needs into it.  During operation, it then calls the command line exe and dumps the output to a temp file named as the current ISO timestamp.  I thought this would be enough granularity (to the second) until stefanobrunesci's reported issue made me think that two concurrently running scans could attempt to create temp files with the same name and write to them at the same time.  This, perhaps, was what was causing stefanobrunesci's issue.  So, to solve it, the change I made was to have each running instance of SFV Ninja work out of its own unique temp folder.  The files it extracts total around half a meg so I'm not worried about multiple temp folders, etc.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version