.NET MD5 Calculation for Large Files

[Phillip Brooks]

I was looking for a method to validate large files in LabVIEW. The NI MD5.LLB source required passing a string which is not practical for a multi-megabyte file. I researched the .NET MD5 functionality, and put together this VI (LV Version 7.1). The .NET implementation is quite simple.

I tested this VI against the labview_80.exe download (~450MB) and FastSum 1.3 Standard and was able to verify my download; see Download LabVIEW 8.0 Now! thread...

FastSum took over a minute to run, the .NET calc called from LabVIEW took ~ 30 seconds...

Enjoy!

Download File:post-949-1133361444.zip

[Mike Ashe]

Thank you very much!

[Phillip Brooks]

You're welcome...

There was a question about GUIDs on Info-LabVIEW. See attached...

I tried to create a quick .NET version;

Place a .NET Refnum on your front panel.

Associate the Refnum with the class System.Guid You will find this by browsing and selecting the file mscorlib.dll. On my XP machine the path was C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll

Invoke the method NewGuid, then pass the NewGuid Refnum and invoke ToString.

As always, clean up your references by closing them.

From what I've read, this implementation may use a hardware specific value (network MAC address?) as a seed for the GUID.

http://lists.ximian.com/pipermail/mono-lis...ary/003109.html

Download File:post-949-1133787439.vi

[HeaVy]

Hi,

The MD5 ComputeHash.vi is a handy tool indeed, but there is one problem that I haven't been able to solve. If the MD5 ComputeHash.vi is a sub-VI within your application and you first execute it and then try e.g. to open the same file that was used by the MD5 ComputeHash.vi, an error is produced (Code 8: File permission error). For some reason the file cannot be accessed or edited until the execution has stopped completely. Don't know why this happens, but I wonder if the .NET functions have got something to do with this even though the references seem to be properly closed.

Any ideas how to get rid of this problem? LabVIEW 8 is no solution since 7.1 is still the default environment in this case.

Thanks.

[LAVA 1.0 Content]

Any ideas how to get rid of this problem? LabVIEW 8 is no solution since 7.1 is still the default environment in this case.

I could not recreate your problem. I made a simple vi that calls the MD5 routine twice, and also loads the md5.vi itself for calculation. I did not receive error code 8.

The only thing I can think of is that some of the high level file I/O functions do not provide an error cluster, and you may be seeing a race condition; the file I/O function is still using the file when the second MD5 function is called, the file I/O function has reserved the file for read/write and the .NET MD5 call is timing out trying to get a file handle.

I assume that you are creating a new file, then calculating an MD5 as a checksum. Try to use the file path out of the write characters to file as the input to the MD5 function to enforce data flow.

Download File:post-949-1153825804.vi

[Darren]

In LabVIEW 8.0, I included a VI at vi.lib\Utility\MD5Checksum.llb\MD5Checksum file.vi that will do the MD5 checksum of a file. The implementation is 100% G, so it will work on all platforms. I haven't benchmarked it against other MD5 methods, but it's there if you need it.

-D

[HeaVy]

Hi,

"I assume that you are creating a new file, then calculating an MD5 as a checksum. Try to use the file path out of the write characters to file as the input to the MD5 function to enforce data flow."

I was checking the MD5 of an existing file, not creating a new one. First I checked it with the MD5 ComputeHash.vi and once the VI was finished with execution I tried to open it with the Open/create/replace File.vi which produced the error code 8. Two other guys tried to figure out as well what's going on, but we got nowhere.

However, we made an MD5.dll with C and that's working just fine so no problems anymore. Thanks for your help.