A helpful VI to create a new file without colliding with existing

[altenbach]

I wonder if it might be better to use a "list folder" with a pattern of the original file name edited to contain the target pattern, but where the number is replaced by a *, then simply loop over the array of names to determine the highest+1 to be used next.

Probably better once a large number of files exist.

[AristosQueue (NI)]

---

Darin.K wrote:

---

Head smack.  Consider how you got to the 1000 files.  By calling it once with 1 file, then once with 2 files, then once with 3 files, then once with 4 files, then once with 5 files.  That is n^2.  Test it if you do not believe me.

---

Ok. I see your point.

Doesn't really affect this function, though... if you're doing those kinds of file writes, you're just going to append a timestamp and not even bother checking for an existing file. This is going to be for saving off log files at the end of a run and things like that. And 1,000,000 calls is, what, a minute and a half total?

[AristosQueue (NI)]

---

@altenbach wrote:

I wonder if it might be better to use a "list folder" with a pattern of the original file name edited to contain the target pattern, but where the number is replaced by a *, then simply loop over the array of names to determine the highest+1 to be used next.

Probably better once a large number of files exist.

---

Begs the question -- is back filling into empty holes desired behavior or not? I'm happy to change the VI if the user requirements are different than what I expected.

[JÞB]

Doesn't really affect this function, though... if you're doing those kinds of file writes, you're just going to append a timestamp and not even bother checking for an existing file. This is going to be for saving off log files at the end of a run and things like that. And 1,000,000 calls is, what, a minute and a half total?

---

The very first time you see that function used in the wild may very well be on This beast (or close to it)

That would be unfortunate since, the real bottleneck would never be found pre-release and no-one would ever read the caveat in the help file.

In fact, its almost garanteed to bite someone fairly hard.  And back-filling missing numbers would be fairly painful. I can't tell you how painful.....

[AristosQueue (NI)]

Altenbach -- reversing the directory listing isn't simple... that *requires* that the directory listing come back in numerical order OR that we are able to extract the integer out of the file names and then sort those -- both of which we've mentioned as difficulties earlier in this thread. Any proposal on how to make the Scan From String find the last string that matches the given format string? Because I sure don't know how to do that.

[JÞB]

---

@AristosQueue (NI) wrote:

Altenbach -- reversing the directory listing isn't simple... that *requires* that the directory listing come back in numerical order OR that we are able to extract the integer out of the file names and then sort those -- both of which we've mentioned as difficulties earlier in this thread. Any proposal on how to make the Scan From String find the last string that matches the given format string? Because I sure don't know how to do that.

---

Scan them all, take max, store in a secure location that no one else can get to linked to this filename to match.

And yes, we would probably need a "uniquifier session" to make the grade.

Thats just one approach that came to mind

[tst]

---

@Darin.K wrote:

You have already combined two functions into a single VI (find the desired filename and then create it) which is a  violation of my tenets for reuse code.  Adding more functionality via more complexity is moving in the wrong direction IMO.  If this is going to ship with LV it should do one thing, do it very well, and be as simple as possible.

---

And there, folks, is the second hardest problem of API design. The first hardest is "what do we name this thing?" But right after that is, "How granular should the API be?"

Sure, I can break it into two separate VIs, but even if I do that, what's going in the palettes is almost certainly one operation. Why? Because if I put two in the palettes, I'll hear about it from a wealth of people that "I always use these together, why are you making me drop both of them or create my own subVI that I now have to maintain ... everyone is constantly creating their own subVI of these two together... can't you just give me ONE VI?!"

---

There is another consideration here - if you split it, you just know that someone somewhere will create a race condition by calling the naming VI twice before creating the file, thus generating two copies with the same name, which is exactly what this code is meant to prevent, unless you guarantee that each call to the VI returns a unique name.

[AristosQueue (NI)]

---

tst wrote:

There is another consideration here - if you split it, you just know that someone somewhere will create a race condition by calling the naming VI twice before creating the file, thus generating two copies with the same name, which is exactly what this code is meant to prevent, unless you guarantee that each call to the VI returns a unique name.

---

Good catch.

So, we create a database that maps onto a file directory that knows the index used to create each file, and a smart file "session" refnum with semaphore lockout so even if the file isn't created we treat it as already in use ... and then... oh dear...

🙂 This is how architecture happens.

[AristosQueue (NI)]

---

@JÞB wrote:

Scan them all, take max, store in a secure location that no one else can get to linked to this filename to match.

---

I don't know how to scan them is the problem. Suppose that we just use the default " (%01d)".
 How do you find the last instance of a scan code in a string? You could have a string like

    (7  (6)  (5).txt

Here's the only way I came up with to do it:

 

[JÞB]

Mobile for now but a regex ought to solve that. course. now you have two problems