Using XPsp3 with its standard DLLs (kernel32, shlwapi, etc) :
I'm trying to make sure that a user-provided path is actually usable, and I've run into a problem: I can't seem to find DLL functions which do that.
As I need an absolute path I've been trying to use GetFullPathName (kernel32), but it doesn't even bother to check if the result is syntactically correct - feeding it something like "file: // d:\folder\file.ext" (spaces not included) makes it return comething like "d:\currentpath\file:\d:\folder\file.ext", which is absolutily bogus.
I thought that PathSearchAndQualify (shlwapi) would do the trick, but that internally just calls GetFullPathName (I've disassembled the function), and thus does not honor its "AndQualify" name in the least. :-(
As a work-around I've been using PathFileExists (shlwapi), but although that works it accepts relative paths - and I could not find a function which
would check if the path is absolute (starts with a driveletter, network server, etc.).
To make things even more interresting, I would also like to be able to qualify things like "%temp%\file.ext" and "D:\%username%\file.ext"
How do I qualify a path using the standard DLLs functions (read: not trying to check for all bad cases myself) ?
For me, I simply use `GetLongPathName()`.
If the input path may contain environment variables, I'd process
it with `ExpandEnvironmentStrings()` before passing it
Lolz : it returns "C:\Windows\System32\..." (thats three (or more!) dots) as valid, but "C:\Windows\System32\...\config.sys" as invalid. Go figure.
Among others I tried PathIsRelative (shlwapi), but thinks that a path
without a drive but starting with a backslash is absolute ... PathSkipRoot doesn't want to skip the drive infront of a relative path (like "c:folder").
I haven't checked, but SHELL32's `PathResolve()` seems worth a try.
I had, based on its name, the same idea. Alas, MSDN (docs.microsoft.com) seems to have thrown all documention about it away. :-(
But "PathResolve" is the first entry of Gugle, DuckDuckGo, as
well as docs.microsoft.com search results. (O.o)?
Mind you, the (console, testing) program is ran from a folder on the the D: drive.
"+" means ok, "-" means fail.
- 'Hello.vbs' ;Fail
+ 'C:\Hello.vbs' ;Fail, twice.
+ 'C:\Hello.vbs' ;Fail
Also, remember those triple (or more) dots ? Those do not get the function to fail either.
All those seems-to-cover-all PathXXX functions... None of them
can do the most basic thing. How shameful and hilarious.
And this morning I realised I had almost forgotten about Alternate Data Streams, the names of which get appended to the filepath using the, normally forbidden outside of a drive prefix, colon character ...
Somehow I don't think that MS really bothered with actually checking if the syntax of a filepath is correct. Instead they seem to have just left it up to functions which actually needed the paths to open files (or devices, pipes, etc) to error-out on the malformed ones.
Why is it that I always seem to run into these kind of "must be simple, but isn't" problems ? :-\
By the way: Did you know that there also isn't any function that checks if a filepath points at a disk/storage-medium file ? I looked for it, but could not find any either.
That actually depends on the file system. e.g. file system other
than NTFS and ReFS.
And in terms of NTFS, you've only discovered 66% of it. There's
a third colon usage to separate between stream name, and NTFS
Why is it that I always seem to run into these kind of "must be
simple, but isn't" problems ? :-\
I could only guess that they think that it's not worth it, considering
that the validity of a file system path depends on the type of the file system - which can not be retrieved from the path name string alone.
GetDriveType(), QueryDosDevice(), and GetVolumeInformation();
There are more options if the input is a file/directory/disk handle.
|Location:||Huddersfield, West Yorkshire, UK|
|Nodes:||16 (1 / 15)|