LabVIEW
Note on Error 7 with the Move VI
I couldn't find any information regarding this when I searched with my error code, and was quite perturbed by what seemed a silly error message.
I wrote a small VI to move some files after installation of a package using VIPM. This VI only iterated over a string array to form a list of file names, then moved them to another directory.
The key flaw in my VI was that I didn't check for the existence of said directory, instead believing it would also be created. Knowing the problem, this is easy to fix using the 'Check if File or Folder Exists?' and 'Create Folder' VIs. In hindsight (having used some Linux OSs in the past) it was fairly obvious.
However, the error message that the Move VI returns when the directory in this case doesn't exist tells me that the Target File doesn't exist. This left me (and I imagine, would leave others) wondering why LabVIEW was being so strange. Certainly I thought it odd that I couldn't write to a file that didn't exist using a VI named 'Move'!
You cannot create a file in a folder that does not exist either. I think there is something about this in the Idea Exchange. Will search when I have time.
But what I do is just create the directory and clear error code 10 ("duplicate path" error when creating a directory that is already there).
crossrulz wrote:
You cannot create a file in a folder that does not exist either.
Right - this was the issue I didn't realise. The reason I posted was that the error message specifically says the 'File' cannot be found, which doesn't immediately conjure up the idea to check for a directory - instead, I was confused as to why it mattered if the 'target file' existed, provided that the source file existed.
But what I do is just create the directory and clear error code 10 ("duplicate path" error when creating a directory that is already there).
I guess that might be more direct, but the 'Check if ... exists' worked OK for me. Perhaps your method avoids me finding a file and then thinking it's a directory?
cbutcher wrote:
But what I do is just create the directory and clear error code 10 ("duplicate path" error when creating a directory that is already there).I guess that might be more direct, but the 'Check if ... exists' worked OK for me. Perhaps your method avoids me finding a file and then thinking it's a directory?
There is also the weird race condition that is very unlikely with File IO, but the directory could have been created between you checking to see if it exists and then you creating it and you end up with error code 10 anyways. Yes, this is extremely unlikely on a local machine, slightly more possible on a network drive.
I take this approach due to an error that was discussed during a CLA Summit. Somebody had a VI that would check to see if a queue reference was valid and if it was enqueue some data. But they somehow ran into a condition, fairly regularly, where the queue was destroyed between the checking to see if it was valid and using it. Took the developer weeks to hammer it down and even then spent all night with an NI R&D guy (bribed with food) to figure it out. Their final conclusion was to just use the queue and handle the error when the queue is not valid.
Oh, and here is the idea I was thinking about: Open/Create/Replace File Function - create file's path if it does not exist
crossrulz wrote: (some long time ago!)
I understand trying to find the balance. But ever since this file IO primitive was introduced (sometime around 8.2?), when I told it to create a file at C:\foo\bar.txt, I was always in shock when I get an error saying that it couldn't create my file because the directory foo did not exist. "File not found?!! You are supposed to MAKE the $#%@!#$ file!"
Guess I just didn't search hard enough for the same issue!
Well, the direct bug fix is to update the error message to specify "File or directory could not be found." You may think that is lame, but it is the easiest and most consistent fix to this problem. Generally I would myself never expect that file in a message would only mean a file and not also possibly a directory.
As to fixing this in other ways, adding extra error codes to be able to construct all kinds of very accurate error messages for every possible case is a maintenance nightmare that never will work out in the long run anyhow.
As to making basic file IO functions gather for almost every possible problem and do the right thing for the user is also a tricky one. You mention Linux where the basic system calls usually only do exactly one thing and that thing only. Windows has several layers of File APIs, with the lower level Win32 APIs doing the same. There are higher level APIs in Windows that belong to the shell32.dll and are really mostly functions from the various File Manager and Windows Explorer versions that Microsoft developed over the time and then moved the functions into this DLL for use by other applications. However some of those APIs like the SHFileOperation() function are so complex that calling it correctly is an art in itself. This single function can do anything from copying, moving, deleting and renaming files and directories, from single to multiple files and/or directories and complete hierarchies, with or without progress dialog and a few dozen other possible options. It's a complete nightmare in terms of usage, and I don't even want to think about the maintenance terror one has to go through when one of the Windows developers wants to make a tiny change to it. Most likely they have a policy inside Microsoft that anyone who even dares to think about modifying anything on that function, will get shot immediately 
Should LabVIEW file IO functions try to be smart and do such things? I tend to say no, even-though it's a higher level programming interface than OS system calls. There is something to be said about failing early on such problems that the programmer didn't explicitly request. While creating an intermediate directory that doesn't exist, is a fairly harmless operation, even if it wasn't meant to be done, this can't be said about deleting or renaming/moving entire hierarchies. But here the LabVIEW Delete File/Directory function did receive an extra boolean to delete the entiry hierearchy in 8.0. Before you could only delete a single file, or a directory that was totally empty. So in that respect there could be an argument about making the Move and Copy smart about creating intermediate directories, if necessary.
But it's an unlikely change to happen for LabVIEW 2017 and most likely for a few more versions after that.
I think the string change for the error message would be just fine. I saw a CAR is already filed, but I couldn't find a version it was fixed in and since I'm hitting it in LV16, I guess it hasn't been changed yet. As to considering both 'files' and directories - I should have, but I didn't, and I suspect I might not be the only person who wouldn't immediately consider a missing directory when both the message and the filename that is passed into the error are for the target file, rather than the missing directory. I just read the error message and fixated on the 'File does not exist' message.
It might be nice to be able to create intermediate directories, as suggested in the idea above, but I don't think a reuse subVI to create and clear the error if it exists is too challenging to build - if I start doing this all over, I'll just create one and use that. There are presumably plenty of more useful things for LV R&D to do than maintaining a VI everyone can easily create if they need, and debug as they experience problems.
@cbutcher wrote:
I saw a CAR is already filed, but I couldn't find a version it was fixed in and since I'm hitting it in LV16, I guess it hasn't been changed yet.
That CAR was for the help file. If you look at the Open/Create/Replace File, there is a sentence that was added to the Path input about non-existent folders. Not sure when it was added, but is there in LabVIEW 2016.
