Function to to verify file name validity...

I think it would be useful to have a function/keyword (similar to the "EXIST" keyword) that would test whether or not a given path/file name is valid; not whether or not it exists, rather just whether it could exist. I make this distinction because there are instances where a file name/path can be absolutely syntactically valid, but not (yet) exist. A perfect example of what I mean by this would be the command "MD D:\A\B\C\D\E\F" /D", which would, of course, create that directory tree and CD into it. However, I'm not sure at this point if the drive letter should be checked for existence because, simply put, it can be "made" to exist at any point in time if it does not exist simply by using the "subst" command. Also, the existence of the "path" part of a file name/path can be easily determined by using the existing EXIST keyword (although the path would have to be separated from the file name) if that is what is needed. The reason this comes up, just so I can make it clear exactly what I'm looking for, is that I have a batch file that displays a dialog box asking the user for the name of a file that may be created sometime in the future, and I would prefer that the user of this batch file know that the file name is invalid and therefore can not be created at the time it is entered rather than waiting to later and having the attempted creation fail. (In the interim I will probably write a C++ program...)

 

Yes, but both for the path spec and the file name itself as well as forbidden character combinations/ill-formed paths ("\A\B\..\.\C\D\E" or "Q\\R\\S" are admittedly rather unlikely examples), total path/file name lengths exceeding MAX_PATH, invalid names like NUL.txt, PRN.doc, CON.cpp (yes, these are all invalid file names despite the fact that they do not have the terminating colon; try to create a file using any given device name and you will see what I mean), not all devices/file systems support all given file/path names that might be valid for other devices/file systems (R/W CD & DVD drives are one example, as well as FAT16, FAT32 vs. NTFS), and more other cases than I can think of and/or are willing to list at the moment, which is precisely why I didn't want to write that code myself if I didn't have to.

If you visit http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx you will at least get a glimpse of precisely how many cases one has to consider, and I have thought of several myself (and tested them!) that that article didn't even mention.

I will also admit that I am kind of a fanatic when it comes to coding, I absolutely will not under any circumstances if I can possibly avoid it allow a user of one of my programs to supply data to that program that will be rejected by the operating system or some other program that is involved in the process that I am trying to create, particularly when handling that error is beyond my "input" stage in the total process and therefore what happens is outside of my control. (Not to give a wrong impression here, no, I do not think of "everything", but I do try very hard to come as close to that goal as I can possibly manage.)

 

Steve, thank you for your response. I'm sorry I haven't gotten back to you sooner, but my DSL modem died the other day and it's taken me until now to be able to connect to the internet again. As far as your ideas/suggestions go, I will look into them in some more detail and get back to you when/if I have anything to ask/add. (Although I must admit that I find the idea that it is "not feasible" to be a little bit suspect, if nothing else I can try to make a zero-length file or directory of that name and see if that succeeds (and delete the file/directory once I know that it has succeeded). And as far as "For some devices this may result in the irrevocable creation of the file, which is not your goal." goes, I haven't ever encountered that (although I am not arguing that that might not be the case for some rather "strange", in my opinion, file systems, but I consider that to be a small enough risk for me and the intended users of my batch "programs" that I can safely disregard it. And I will also note that the "@Unique" function also obviously disregards that possibility.) But I absolutely would prefer to do as many checks as I possibly can before going to that last, final, step, and ironically, just for the reason you previously mentioned if nothing else). And as far as "%@DEVICE" goes, thank you, I wasn't aware of that function (as I have mentioned several times previously, because of my bad eyesight I tend to read almost strictly on an "as needed" basis, and I have never seen that in the documentation before as far as I can remember). And, as a final point, I knew that path names like the above are generally valid; I just just don't consider them to easily decipherable by a human being. (It's completely non-relevant to me if a "program" creates paths of that form "internally" because they will never be seen in that form by any human being (other than possibly the person that is "debugging" the program), although I must add that it might make the debugging of that program somewhat more difficult. And if you actually try some of them (which I have done) you will see what I mean regarding "human readability. Although the "@TrueName" function might alleviate that situation somewhat.) But that's a relatively minor concern...