Increment File Suffix Without Creating a File

[Hooovahh]

Starting in LabVIEW 2015 we got a neat new function that can create a unique file path, and allows to not overwrite a file that might exist with a similar name.

  

This is such a cool function and I could think of a ton of places where I needed to save some temporary data and just wanted a unique name expecteing files to be cleaned up later.  Or give the user a checkbox which wouldn't overwrite the existing data, and then not need to worry about generating my own unique name.

Alas this function fell short of my expectations.  Why?  Because it creates the stupid file, and returns a reference to it, instead of just generating a path that I can use.  What if I want to use this with the report generation toolkit and generate a unique file name?  Well you can but you need to close the file reference it made, and possibly delete the file.  Same with if you want to use this on a TDMS file, or a Configuration INI file, or a zip, etc.

I suggest either adding another function (polymorphic?), or making an optional input to this function, which does everything it currently does except don't run the Open/Create/Replace function there by making the file, and returning a file reference.  Every time I've used this function to date it has been followed up with a Close File, then a Delete function.

[RavensFan]

Well it IS actually called "Create File ....." 

[altenbach]

It would be easy to change and create your own variation. The code if the existing tools is public, so all we need is bypass the rightmost parts of the code. 😉 (... and make a "Create file path with incrementing suffix".)

But yes, maybe the file creation could have been left out for a more flexible tool. Many times, a file reference is not needed (e.g. write to spreadsheet file, write to text/binary file with a path wired, etc.)

[Mads]

I guess the reason they have done it this way is that they can avoid collisions/race conditions this way. If it did not create the file on the spot, but only gave you a path, some other process might generate a file in that path before your code did.

The function could be split though: It could have a subVI ("Generate Unique/Unused File Path (in given directory).vi") that generates a path that is probably not in use, and the rest would actually generate that file and hand off the file reference. This latter part should handle situations where the file path turns out to not be uniqe after all, and call the path-generating subVI again until the whole process succeeded (looking at the internal code I see that this is not done, it will just fail if the file has popped up already). The "Generate unique file path" subVI should then be made available in the palette too - so that you can choose to use it, and handle the possible race condition yourself. The subVI could be reused by NI in their "Generate Temporary File Path.vi".

The code needed within the "Generate Unique/Unused File Path (in given directory).vi" is already available within the Create-VI so you can make it yourself pretty quickly (but yes, it should be included in the standard vi.lib from NI). 

So to summarize; I think it would be better to propose a new/different idea; namely to have a Generate Unique/Unused File Path (in given directory).vi...(and again this could then be used as part of the other currently available library funtions).

[Hooovahh]

Yeah I guess this is a relativly minor thing to want, and easily done by a developer.  You can simply take the NI VI, save a copy as your own, and not perform that last function, but I generally try to avoid this type of thing, because what if in future versions of LabVIEW NI comes up with some kind of improvement to their file name generation?  Or what if NI finds a bug that they fix in a later version?  In these cases my code that took the 2015 version of the VI and saved a unique copy won't have these fixes, which is why I thought a VI that is this function, with a close reference, and a delete might work best.  But to be honest I don't see NI making any major improvements to this VI in the future.

[RavensFan]

Is it a huge problem if the file gets created?  What if you just close the reference immediately after it is created?  I imagine you are left with a 0 byte file that you could later reopen.  Or just Close the reference and immediately delete the file.

Either of these options would leave the original subVI intact that would get updated in future LabVIEW versions, but would only had 1 or 2 steps immediately after to get what you want.

[Hooovahh]

If you just close the reference a 0 byte file is created.  It can be a problem when it comes to some toolkits I've used.  There was a PDF generation toolkit that in the save function it would detect if the file you were trying to save it to existed already, and if it did it would prompt you to overwrite it or pick a new file name.  I didn't want that dialog seen, because it was an automated process so I got in the habit of creating the unique name, having it make the file and reference, close the reference, then delete the file.  So yes, two additional steps to maintain compatibility.

[AristosQueue (NI)]

> So yes, two additional steps to maintain compatibility.

Two steps that can be done once and wrapped in a subVI and still maintain full compatibility if NI changes the code? 🙂

> I guess the reason they have done it this way is that they can avoid collisions/race conditions this way

Yes. Well, that and the use case we were addressing was people trying to save data files or log files or whatever, and you're at the point of wanting to save, so giving back the refnum let you immediately procede with saving the data. We didn't have a use case for this kind of "pick the next available number" where LV wouldn't create the file.

[Hooovahh]

> We didn't have a use case for this kind of "pick the next available number" where LV wouldn't create the file.

Oh don't get me wrong LabVIEW would still be creating the file in my other cases, but assuming that I want to only make a text file is where I think the function limited its usefulness.

I agree, three functions wrapped into a subVI isn't terrible (Create File, Close File, Delete File), and moving forward this is what I'll be doing.  I just thought it odd that this wasn't the intended purpose.