|
|
Comments and Discussions
|
|
 |

|
Hi there,
Quick question
Can the IsValidFileName be compiled using the Visual C++ "Express" Edition? I am still fairly new to C++, so my trouble could just be an oversight.
Here is the output I get.
------ Build started: Project: IsValidFileNameTest, Configuration: Debug Win32 ------
Compiling...
IsValidFileName.cpp
IsValidFileNameTest.cpp
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(216) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(216) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(216) : error C2228: left of '.pFileName' must have class/struct/union
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(216) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(218) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(218) : error C2228: left of '.pFileName' must have class/struct/union
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(219) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(219) : error C2228: left of '.result' must have class/struct/union
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(221) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(221) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(221) : error C2228: left of '.pFileName' must have class/struct/union
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(221) : error C2065: 'test' : undeclared identifier
c:\documents and settings\justin\desktop\isvalidfilename_demo\isvalidfilenametest\isvalidfilenametest.cpp(221) : error C2228: left of '.result' must have class/struct/union
Generating Code...
Build log was saved at "file://C:\Documents and Settings\Justin\Desktop\isvalidfilename_demo\IsValidFileNameTest\Debug\BuildLog.htm"
IsValidFileNameTest - 13 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
One other question. When the app runs, does it monitor the entire file system? Or do you specify a particular directory for name validating to occur in?
Thank you,
-Justin
|
|
|
|

|
OK...
Got it to compile, line 216 had a missing int.
Though nothing happens when I run the app. If I understand this correctly, the app should print a custom messages to the screen if I try to create a file with an invalid name, consequently also preventing me from creating the file. For instance, I should not be allowed to create file named "clock$", "console", "auxx.aux.txt" etc.. Is that correct?
If that is correct, then something is wrong. After I launch the .exe I proceed to create files, with invalid names, such as from the previous examples. I get no alerts, no message, the file gets created.
A few things I notice, the IsValidFileNameTest.exe does not show up as a process in the Task Manager. Also noticed, the .exe I compiled is about 400K larger than demo one.
I have McAfee running, could that be the cause? McAfee hasn't given any alerts though.
|
|
|
|

|
The missing int is due to the change in scoping rules of for() constructs being enforced in VS 2008.
The demo is not interactive. It simply runs through arrays of reserved filenames and checks the error return. It does NOT stop you from creating anything, it's merely a check.
Clock$ is an odd one. Microsoft documents this as a reserved name, but it can be created. For reasons lost in time, I chose to treat it as reserved (I suspect that under Windows 98 it was still reserved, but don't remember if that was the reason.)
auxx.aux.txt is a valid filename and the test reflects that, only AUX is not.
As for the size, I don't have express, but did compile it under VS 2008. The debug version comes out to 450k. It's 58k under release mode. Seems normal. If I used dynamic linking it would be much smaller (11k for release.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|

|
I think it would be possible through a driver, though I'm not sure how much control you really have over such a thing.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|

|
The shell also appears to dislike names that start with dots and spaces. For example ". .x" is not accepted. "x. .x" works, but if you try "x. ." it gets changed to just "x".
|
|
|
|

|
char* filename = ". ll";
cout << IsValidFileName(filename) << endl;
-------------------------------------------
0
if you file name like this ".ll";
i think a bug in your code!
i like java
|
|
|
|

|
I just tested ". ll" and ".ll" and both passed (return 0). (Those are 2 little-L's.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|

|
PathIsDirectory() seems to have the same function.
|
|
|
|

|
The stated purpose of this code is to return the reason the path is invalid, not to simply fail if the path is invalid. This code will help give better feedback to the user. If such feedback is not required, then PathIsDirectory() is a good alternate (and one I have used.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|

|
Ignore the bitching below. This is real-world useful code. I had to write a similar version years ago that is still in use in commercial products. The whole point is to filter out and handle common naming problems before they get to the file system. I wish I would have had this to reference back then.
|
|
|
|

|
Good job!
Since MS don't provide an API like this, I think this function is very useful.
-- modified at 20:49 Tuesday 15th November, 2005
|
|
|
|

|
check this out...
go to the command prompt (cmd.exe)
type:
c:>md clock$
now go to explorer.exe and find the directory clock$ and try to delete it.
Jeremy.
Jeremy Pullicino
Professional C++ Developer
Done any hacking lately?
|
|
|
|

|
As nice as this seems to be at first, it fails in many situations.
The checks for devices are not necessary because they work only with the predefined devices. Any driver may install additional devices with DOS names which may interfere with otherwise legal filenames.
You can use this function only as part of the verification. In the end you cant avoid callig CreateFile trying to create a new temporary file for read/write access.
In general using Shell's Path... functions together with CreateFile() is the only safe way.
just my 2 cents.
...if you're under 8 or younger. Chris Maunder, the Lounge
|
|
|
|

|
The intent was to simply indicate compliance with the basic rule set of file names and enable a utility I was writing to generate a sensible error string for the user if those rules were violated.
I freely admit this is overkill since the most common check would be for the illegal characters, which can be done with strchr(). However, I decided to enforce the full documented set since it is documented and known.
Most developers simply create and/or open a file and read/write away. This offers a simply check to do beforehand.
Andreas Saurwein wrote:
In the end you cant avoid callig CreateFile trying to create a new temporary file for read/write access.
Actually, you can. If this function fails, you don't call CreateFile! And, as I pointed out, few developers do any checks at all--if CreateFile fails, they display an error and are done with it.
Finally, the list of documented device names is a reserved list. Those devices may or may not actually exist.
But, of course, if you don't find it useful, don't use it! I found this useful and am using it.
|
|
|
|

|
It may be useful in certain situations, but then again, most existing API solutions to choose/enter filenames do already validate, you just have to use them instead of developing homegrown input methods (although one can't avoid that always).
Also, I wonder what difference it makes how fast this function is. The user needs in any case thousend or more times longer to enter a filename. So what? This is optimizing where no optimization is needed. Smaller and maintainable would be better.
Again, just my opinion.
...if you're under 8 or younger. Chris Maunder, the Lounge
|
|
|
|

|
Again, the current usage is a command line utility--in this case a utility which churns through many files (an added caveat was that the user did not enter the entire file name, with the program entering the rest. In a second utility, the dialog prompts the user for a new file name for a rename operation.)
Another place I used a similar function (which checked for only the "just dots" scenario), was when reading a filename from the registry. If I still worked at the company, I would replace the previous function with this one.
Andreas Saurwein wrote:
Smaller and maintainable would be better
The scanning solution I mentioned was actually bigger and I find this code quite maintainable.
|
|
|
|

|
I don't get your point for questioning this code.
If it fails then it has bugs, but I don't think this code to be a bad idea.
An example of where this code could be useful is a FTP Server.
I developed many applications where clients had the ability to send files to the server, and this validation (together with other) was necessary.
How to you suggest doing this?
Even more, to make this applications UNIX compatible, I tried to avoid Windows specific functions at protocol level.
|
|
|
|

|
Code may fail because of other reasons not only bugs. It may be because of the design, the intended environment, etc.
I this case, its not a bad idea to use this code. It will probably suffice in 90% of all cases. For the remaining 10% you have to be additionally careful and add other methods of verification.
And you comment about unix (in regard to using this code at least) is completly void because you have pretty different constraints on a unix filesystem.
...if you're under 8 or younger. Chris Maunder, the Lounge
|
|
|
|

|
Andreas had some good points in his original comments and I changed the article to hopefully make it more clear that this is a narrow test.
He is also right to point out that when creating files through the shell UI APIs, this validation is usually done for you, though the error may be confusing or non-existent. (Try renaming a file using an invalid file name through file manager.)
Like I said, I've found this useful for command line utilities and when reading file names from the registry.
|
|
|
|

|
Joe Woodbury wrote:
He is also right to point out that when creating files through the shell UI APIs, this validation is usually done for you, though the error may be confusing or non-existent. (Try renaming a file using an invalid file name through file manager.)
Actually, File Manager is even more restrictive in the allowed rules. The following names are legal, but FM won't allow you to create them:
".foo" ("You must type a filename" (!))
" foo" (No error, FM silently remove leading spaces)
"Foo .. g" (OK)
"Foo..." (No error, FM and Windows API silently remove trailing dots)
And so on...
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
Function to determine if a file name is valid.
| Type | Article |
| Licence | |
| First Posted | 5 Oct 2002 |
| Views | 95,460 |
| Bookmarked | 23 times |
|
|