Check if file opened tales to long?

[altenbach]

Yes, each operation takes 100ms, but several instances can be run in parallel, giving a proportional speedup, so that is a partial solution if many files need to be checked. The individual operation still has a fixed duration.

[BowenM]

---

@altenbach wrote:

---

@BowenM wrote:

I did a test on my machine out of curiosity.  100ms seemed like a long time to just open / close a file.

---

The way I understand the problem, the 100ms delay occurs if we try to open a file that has already been opened elsewhere.

---

I missed that part of it.  I had a couple open files to make sure that it detected them as open but most were closed.

Just FYI I also tested this with a call to the System.FileIO .NET and it was slightly slower.  I think hoovah's suggestion is your best bet.

[AntonioNI]

So, lets say my data is **bleep**mented in 50 CSV files and the program writes in to them cyclically. How to figure out the current used file without this delay? The problem is I'm monitoring up to 24 different CSV (each one fragmented in 50) and even if I only have to check once to keep track of the file it would take too long. But I guess I could watch out for the next file in line till it gets opened since that last micro seconds... I'm sure there's a smart simple way to do it. I'll keep thinking xD thanks for the help

[AntonioNI]

Fragmented****

[rolfk]

Most likely not without diving quite deep into Windows API calls. The most common way to check if a file is still opened in another application is by trying to access it. Windows seems to have a built in retry mechanisme when that call fails. There is no easy way to disable that. If I understand the post from BowenM correctly this same thing happens in .Net too, hinting at the fact that it is a Windows thing.t 

You could try it yourself by calling the Windows API CreateFile() directly to see if that shows the same delay. Ultimately that is the function that the LabVIEW OpenFile function calls internally too. If CreateFile() shows this same bahviour it's probably going to be a though cookie to work around this and a review of what you are wanting to do is required.

Hmm, you have a good chance that calling CreateFile() directly is going to help here. I found in some old documents that the LabVIEW FileOpen function internally calls CreateFile() multiple times when it fails because otherwise it would randomly fail for MS utilities like FindFast and similar accessing files in the background for indexing purposes. This is at the same time another issue: CreateFile() failing doesn't necessarily mean that your other application has the file still open. It could be also some file indexing service that is opening the file to see if there is something to add to the search index.

So while calling CreateFile() directly is a workaround for the problem at hand, it is not a proper solution. Rather than causing long delays when trying to open an already open file it can give you false positives and is prone to race conditions too. The CreateFile() call can succeed but immediately thereafter the other applciation opens that file and your conclusion is now invalid.