sth

Came across this comment looking for something else and a little late, but.... I know that Greg McKaskle was discussing this as a standard technique in late 1994. http://info-labview.org/ILVMessages/1994/12/02/Info-LabVIEW_Digest_1994-12-02_005.html

Makes sense to me! I wasn't sure where it was superseded by the native LV code, probably 2009 is a good cutoff for not including it in the standard toolkit. So who does the toolkit packaging? The base package should just be marked Windows only.

The OpenG Large File Library claims it is on all OS Versions but since it calls :kernel32.dll I am assuming that is not accurate. I doubt that it is needed in OS X since LabVIEW version XX (12 at least) handles file position values as I64. But if you load the OpenG Toolkit for Mac OS X you get a bunch of errors as it tries to deal with this package. Probably just removing it from the Toolkit would suffice. I expect that the newer versions of LV on windows also handle large files. Scott OpenG Large File Library v4.0.0.3 by OpenG.org Released On: Sat, 25 Jun 2011 20:41:08 -0700 Author: OpenG.org Copyright: Copyright © 2007 Rolf Kalbermatter; 2010-2011 Jonathon Green License: BSD Compatible LabVIEW Versions: >= 2009. Compatible OS Versions: ALL. Repository Name: VI Package Network

Well it is good to keep a the old file until you sucessfully write a new file. In terms of say "hard links" to the file it is significantly different to create a new file and delete the old file. The best way to do this in terms of safety and not messing things up, is to create a backup of the original file (if possible since you may not have write access to the directory) and then attempt to update the original file. If it all fails then put the old data back and abort out. This way if the OS aborts while the file is open you have the backup.

I find it a clunky interface to the normal directory structure. So I usually just Open a VI and then click to the LV application directory and I am used to finding stuff there. Maybe I should give it another chance. It used to be very problematic about finding things.

I think things will return to normal now. I have gotten both the campus DNS correctly configured and the nhmfl.gov domain pointint to the correct servers. It will take about 1 day to propagate the fixes through the DNS system but all will be well. This was a bad week. -Scott

The info-labview server is not down. And I believe that a message went out to the list to that effect. However, the DNS for the server has been foobared by my university (not the lab) so it is not something I can go down the hall and fix. I have a ticket established but their response time is abysmal. The message that went out was rejected by a LOT of systems since it came from a machine without proper DNS. In summary: I can post as can anyone inside our lab who uses our local DNS, which is working. The faulty entry was the whole nhmfl.gov domain. The primary DNS gave a server error. (dns1.fsu.edu) The secondary DNS gave the correct reply (dns2.fsu.edu) I will post again when it gets up. This has been complicated since our spam filter went nuts and threw 7000 messages in my junk mailbox and some were not spam. This has overloaded the spam filters and our local mail system is bogged down. I will post again when things are more normal. -Scott

This is a limitation of the ISO-9660 file system for standard CDs. There are propietary file systems that allow you to use more liberal file names BUT they are not universal. Joliet and Rockridge are two key names for extended file naming systems.