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...)
Function to to verify file name validity...
- Thread starter mathewsdw
- Start date
On Thu, 26 May 2011 03:02:06 -0400, mathewsdw <> wrote:
|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...)
I don't get it! As you pointed out, any path that doesn't contain forbidden
characters may **could** exist. Is that what you want ... a test for whether a
path spec contains forbidden characters?
|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...)
I don't get it! As you pointed out, any path that doesn't contain forbidden
characters may **could** exist. Is that what you want ... a test for whether a
path spec contains forbidden characters?
On Thu, 26 May 2011 03:02:06 -0400,
I don't get it! As you pointed out, any path that doesn't contain forbidden
characters may **could** exist. Is that what you want ... a test for whether a path spec contains forbidden characters?
I don't get it! As you pointed out, any path that doesn't contain forbidden
characters may **could** exist. Is that what you want ... a test for whether a path spec contains forbidden characters?
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.)
From: mathewsdw
| From: vefatica
|| I don't get it! As you pointed out, any path that doesn't contain
|| forbidden characters may **could** exist. Is that what you want ...
|| a test for whether a path spec contains forbidden characters?
|
| 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.
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
| From: vefatica
|| I don't get it! As you pointed out, any path that doesn't contain
|| forbidden characters may **could** exist. Is that what you want ...
|| a test for whether a path spec contains forbidden characters?
|
| 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.
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
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
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