Jump to content
Sign in to follow this  
Phillip Brooks

.NET MD5 Calculation for Large Files

Recommended Posts

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! :D

Download File:post-949-1133361444.zip

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.