Get File Size returns error 5 for open AVI files (no exclusive mode support)

[EvgenKo423]

This problem also relates to Vision Development Module, but it can be fixed from both sides and it would be better to fix it in LabVIEW in general.

There is a KB article about AVI size limit in VDM (archived), which says:

If you are running into this limit, monitor the amount of data you are writing to the file using the Get File Size Function and programmatically create a new file before hitting the 2 GB limit.

---

However, this suggestion is wrong and you can't use this function with AVI files in any way, because VDM opens them in exclusive mode and the function requests a read(/write !) access (probably because a returned file refnum can be reused later). You can't cast AVI ref to file ref either (edit-time type error or error 1 "An input parameter is invalid" at runtime).

You also can't use File/Directory Info function, because file size does not update until the file is closed.

Nevertheless, exclusive mode is not stopping you from getting file size or other attributes. According to WINAPI reference, you can request file attributes with no access at all:

dwDesiredAccess

If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied.

---

But again LabVIEW natively doesn't let you open a file with no access mode, so the only thing you can do is to call CreateFileA and GetFileSize functions directly from kernel32.dll through Call Library Function Node.

---

Environment:
Windows 8.1
LabVIEW 2018 SP1 f4 - 2020
Vision Development Module 2018 SP1 - 2020

Steps to Reproduce:

1. Create a new VI (or see attached);
2. Open an AVI file for writing using IMAQ AVI2 Create VI;
3. Write to AVI some frames using IMAQ AVI2 Write Frame VI;
4. Use Get File Size function with AVI path to get AVI size during writing;
5. Run the VI.

Expected Result:

File size returned successfully.

Actual Result:

"Error 5 occurred at Get File Size

 LabVIEW: (Hex 0x5) File already open."

Workaround:

Call GetFileSize function directly from kernel32.dll through Call Library Function Node (see attached VI for an example).

Reported to NI with SR #7811213.

[FireFist-Redhawk]

I don't have VDM on my home setup so I can't reproduce the issue or open your VI, but maybe try openG 'File Info.vi'. It appears to get file size and the other attributes via call library function node, and it's already in your palettes assuming you have openG library.

Not saying that will work any differently, but who knows.

[EvgenKo423]

Thanks for the tip, I somehow missed this VI. However, it won't help either.

Essentially it's a wrapper around LabVIEW File Manager functions FGetInfo / FSetInfo and it returns the same size as File/Directory Info function (that is 0 for files being written to).

[Bob_Schor]

A simple Web search shows the problem is your Version of LabVIEW.  To quote from an NI Knowledge Base Article,

Software versions 2019 and onwards:
Starting with Vision Development Module 2019, writing AVI files bigger than 2 GB is supported by LabVIEW. However, limitations to AVI file size exist in individual codecs. If you are seeing this error while using VDM 2019, try using a different codec. See "Additional Information" for a list of codecs that support writing file sizes of at least 2 GB. 

See if that makes a difference.

Bob Schor

[EvgenKo423]

No, the problem is that if, for any other reason, you will need to check a size of any file opened in exclusive mode by another application (and AVI in particular), you can't do that natively in LabVIEW. And there is also a wrong suggestion in the article.

Moreover, it's actually not the only false statement in this article with the quoted one being another. I have a separate report on this subject which was a bit delayed and it's actually the reason I finally decided to report all these bugs.

[AllisonSCJ]

---

@EvgenKo423 wrote:

if, for any other reason, you will need to check a size of any file opened in exclusive mode by another application (and AVI in particular), you can't do that natively in LabVIEW. 

---

You can, if fact, check the file size of a text, binary, and datalog files while they are opened in exclusion mode as the outputs to these vis are byte stream references. I'm guessing what you're saying is you would expect to be able to read a file size from a path input, rather than the reference, when in exclusion mode.

However, Labview's assumption in regards to exclusionary mode is that you wish to have exclusive access to the file. If an attempt is made to open the file to read its size while it is being edited in exclusive mode, the file size that was read may no longer be accurate. This is most likely the reason for the behavior you're seeing. What you're attempting to do goes against how exclusive mode is meant to work.

It would be fair to request a readonly mode for IMAQ, or the ability to cast your AVI reference to a byte stream for use with the other file vis. But what you're describing in your post isn't unexpected behavior in regards to file access.

[EvgenKo423]

There is no such thing as exclusive mode in LabVIEW. You can, indeed, open any file in LabVIEW in write-only mode and be able to access it by name in read-only mode at the same time, because core LabVIEW file functions open files in shared mode and you can't change it as sharing options are not exposed to users.

LabVIEW has no assumptions or handling of file sharing mode, it's all done by Windows kernel depending on how you call it and the root of this problem in incorrect access mode being requested from Windows. I know exactly the reason for this behavior because I took a look at how LabVIEW calls Windows API.

As I said, Windows itself doesn't have anything against it if you ask it correctly:

---

@EvgenKo423 wrote:

Nevertheless, exclusive mode is not stopping you from getting file size or other attributes. According to WINAPI reference, you can request file attributes with no access at all:

dwDesiredAccess

If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied.

---

But LabVIEW requests a read/write access first and if it fails requests read-only access which is denied as well.

[rolfk]

While your analysis is certainly right, you have to consider a number of possible reasons why it is like it is:

1) LabVIEW comes originally from the Macintosh and there from MacOS Classic. When they developed the multiplatform version of LabVIEW they introduced so called manager layers for different functions such as file IO, memory management, resource management, network communication, dialog manager, etc. These were modelled to be similar to the MacOS Classic API, which wasn't necessarely the neatest API you could find, but Windows 3.1 at that time was in many ways an even greater hack and Unix Posix a mess, with many cooks trying to put their thing in it and not agreeing in very fundamental things about it. Each Unix vendor was very carefully shielding its own implementation from other vendors after having forked over a lot of money for a source code license to AT&T or whoever was believed to own the original rights on it. Minix was an open source variant, but it was mostly an educative platform without any importance for commercial applications and it certainly had no way of influencing anything like the Posix consortium in any way, unlike Linux nowadays.

These Manager APIs tried to combine actually different ideas from the underlaying platforms (the file access right flags from Posix were for instance used as they were more functional than what both Windows and MacOS could provide) and many more such things. At the same time this multiplatform approach also limited certain things, as they had to think very carefully about adding features that could not be implemented on other platforms in a good way.

2) Windows 3.1 most likely did not even have this possibility to open a file handle with no access rights at all. The underlaying DOS system doesn't give such capability and Windows had no kernel that would implement such things itself.

3) Last but not least, the Call Library Node lets you call the Windows API yourself and create a workable workaround for this.

Would it be desirable if LabVIEW allowed to access every single feature of the underlaying platform out of the box? Sure! Would it be practical and feasable? Absolutely not! Not even .Net does give you that, and that is from Microsoft itself, with a software team that NI never even can come close at in number of programmers.

[EvgenKo423]

Yes, I agree that there are many reasons for it to be like it is.

Exposing all the underlying features of different OSs in LabVIEW is not the best idea for sure, but I think while these managers are hiding platform specifics from LabVIEW they can at the same time take advantage of them under the hood. I think they shouldn't behave equal on all platforms because platforms don't behave equal either. While these wrappers allow universal access to features, they also allow the implementations to have a different behavior, closer to expectations on a specific platform.

At least a feature should work from one side or the other when it is itself proposed as some workaround.