From: mathewsdw
The basic request - an "IF VALIDNAME" test - is at first blush legitimate.
The samples of ill formed paths above are all legal, and occasionally useful, esp. when they are constructed by a program. The TRUENAME command and the @TRUENAME function translate them to the properly formed equivalents, whether or not the path exists, or - if they included a drive letter - even if no such drive exists.
Testing for name length exceeding MAX_PATH could, obviously, be done only on the TRUENAME.
Testing for device names (AUX COM1 COM2 COM3 COM4 CON LPT1 LPT2 LPT3 LPT4 NUL PRN) is already available: the function %@DEVICE[%@name[x]] returns 1 if the NAME portion of the string x is a device name. (See its limitations without using the @NAME function in a separate post.)
Testing based of file system type would be impossible, because there are file systems which only accept lower case letters, and others which accept only upper case letters, and your network may contain both. NET USE allows you to map conflicting file systems to the same drive letter at different times, and USB ports likewise. You may put a writable CD into a DVD-writer. The only thing you could detect is whether or not a specific name is acceptable to the currently connected file system. Even then TCC may not be aware of the internal naming rules of the file system, and the only way it could validate a name is to try to create the directory or file. For some devices this may result in the irrevocable creation of the file, which is not your goal.
In conclusion, I do not think your suggestion is feasible.
--
Steve
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...