[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

PathFileExists Fails with Quoted Path?

Karl E. Peterson

4/12/2012 10:01:00 PM

How very odd. The shell function PathFileExists fails if it's passed a
quoted string. The kind you'd get as a command line parameter as a
fully qualified filespec, due to the fact that spaces are allowed in
directory and filenames.

This one caught me by surprise, with "File not found" errors coming
from a utility I wrote. Anyone else aware of this?

Repro:

Private Declare Function PathIsDirectoryW Lib "shlwapi" (ByVal
lpszPath As Long) As Boolean
Private Declare Function PathFileExistsW Lib "shlwapi" (ByVal
lpszPath As Long) As Boolean

Public Function PathIsFile(ByVal Path As String) As Boolean
' Combines a few functions, to test if path points to existing
file.
' NOTE: These fail with quoted filespecs!
If PathIsDirectoryW(StrPtr(Path)) = False Then
If PathFileExistsW(StrPtr(Path)) Then
PathIsFile = True
End If
End If
End Function

If you pass a string that includes the surrounding quotes, essentially:

"C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSOXMLED.EXE"

Still mumbling about the pervassive ramifications...

--
..NET: It's About Trust!
http://vfre...
20 Answers

Karl E. Peterson

4/12/2012 10:36:00 PM

0

"Nevermind..." Classic case of posting it causing deeper refection.
OF course that function fails, because quote chars are illegal within
filenames. D'oh!


on 4/12/2012, Karl E. Peterson supposed :
> How very odd. The shell function PathFileExists fails if it's passed a
> quoted string. The kind you'd get as a command line parameter as a fully
> qualified filespec, due to the fact that spaces are allowed in directory and
> filenames.
>
> This one caught me by surprise, with "File not found" errors coming from a
> utility I wrote. Anyone else aware of this?
>
> Repro:
>
> Private Declare Function PathIsDirectoryW Lib "shlwapi" (ByVal lpszPath As
> Long) As Boolean
> Private Declare Function PathFileExistsW Lib "shlwapi" (ByVal lpszPath As
> Long) As Boolean
>
> Public Function PathIsFile(ByVal Path As String) As Boolean
> ' Combines a few functions, to test if path points to existing file.
> ' NOTE: These fail with quoted filespecs!
> If PathIsDirectoryW(StrPtr(Path)) = False Then
> If PathFileExistsW(StrPtr(Path)) Then
> PathIsFile = True
> End If
> End If
> End Function
>
> If you pass a string that includes the surrounding quotes, essentially:
>
> "C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSOXMLED.EXE"
>
> Still mumbling about the pervassive ramifications...

--
..NET: It's About Trust!
http://vfre...

ralph

4/13/2012 2:55:00 AM

0

On Thu, 12 Apr 2012 15:36:09 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:

>"Nevermind..." Classic case of posting it causing deeper refection.
>OF course that function fails, because quote chars are illegal within
>filenames. D'oh!
>
....
>>
>> If you pass a string that includes the surrounding quotes, essentially:
>>
>> "C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSOXMLED.EXE"
>>
>> Still mumbling about the pervassive ramifications...


Yeah, we just had a thread a while back on that. Double quotes are
only needed for shell parsers that use a space as a delimiter for
commands and parameters.

Unfortunately since a program can never be quite sure how it is
launched, or the means by which it is delivered, any 'strings'
received from the outside world need to be tested for leading and
trailing quotes.

-ralph
[DIFF/CVS sources can also be a problem.]

ObiWan

4/13/2012 1:24:00 PM

0


> Unfortunately since a program can never be quite sure how it is
> launched, or the means by which it is delivered, any 'strings'
> received from the outside world need to be tested for leading and
> trailing quotes.

Oh... that's easy, either use whatever API your OS offers or setup your
own cmdline parser trying to resemble what you need, for example...

http://alter.org.ua/docs...

the above is easy to translate to VB code and will give you a decent
cmdline parser turning each *real* arg into a separate array element
then... ok, you may want to push thing further and (as I did centuries
ago) also add a "getopt" function like the one used in "C" to parse the
cmdline args with ease, but that's totally up to you :)

Mayayana

4/13/2012 1:39:00 PM

0

I'm curious why you go to the trouble of API for
that. Is there some advantage over s VB method
like the following?

Public Function FileExists(ByVal sPath As String) As Boolean
Dim i As Integer
On Error Resume Next
i = GetAttr(sPath)
If (Err = 0) Then
If (i And vbDirectory) = 0 Then
FileExists = True
End If
End If
End Function

Public Function FolderExists(ByVal sPath As String) As Boolean
On Error Resume Next
FolderExists = (GetAttr(sPath) And vbDirectory) = vbDirectory
End Function

--
--
"Karl E. Peterson" <karl@exmvps.org> wrote in message
news:jm7lct$qks$1@dont-email.me...
| "Nevermind..." Classic case of posting it causing deeper refection.
| OF course that function fails, because quote chars are illegal within
| filenames. D'oh!
|
|
| on 4/12/2012, Karl E. Peterson supposed :
| > How very odd. The shell function PathFileExists fails if it's passed a
| > quoted string. The kind you'd get as a command line parameter as a
fully
| > qualified filespec, due to the fact that spaces are allowed in directory
and
| > filenames.
| >
| > This one caught me by surprise, with "File not found" errors coming from
a
| > utility I wrote. Anyone else aware of this?
| >
| > Repro:
| >
| > Private Declare Function PathIsDirectoryW Lib "shlwapi" (ByVal
lpszPath As
| > Long) As Boolean
| > Private Declare Function PathFileExistsW Lib "shlwapi" (ByVal
lpszPath As
| > Long) As Boolean
| >
| > Public Function PathIsFile(ByVal Path As String) As Boolean
| > ' Combines a few functions, to test if path points to existing
file.
| > ' NOTE: These fail with quoted filespecs!
| > If PathIsDirectoryW(StrPtr(Path)) = False Then
| > If PathFileExistsW(StrPtr(Path)) Then
| > PathIsFile = True
| > End If
| > End If
| > End Function
| >
| > If you pass a string that includes the surrounding quotes, essentially:
| >
| > "C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSOXMLED.EXE"
| >
| > Still mumbling about the pervassive ramifications...
|
| --
| .NET: It's About Trust!
| http://vfre...
|
|


ralph

4/13/2012 4:05:00 PM

0

On Fri, 13 Apr 2012 15:23:44 +0200, ObiWan
<alb.20.trashsink@spamgourmet.com> wrote:

>
>> Unfortunately since a program can never be quite sure how it is
>> launched, or the means by which it is delivered, any 'strings'
>> received from the outside world need to be tested for leading and
>> trailing quotes.
>
>Oh... that's easy, either use whatever API your OS offers or setup your
>own cmdline parser trying to resemble what you need, for example...
>
>http://alter.org.ua/docs...
>
>the above is easy to translate to VB code and will give you a decent
>cmdline parser turning each *real* arg into a separate array element
>then... ok, you may want to push thing further and (as I did centuries
>ago) also add a "getopt" function like the one used in "C" to parse the
>cmdline args with ease, but that's totally up to you :)

"Easy" appears to be strictly in the eyes of the beholder. The list of
Windows developers and shops that adopt a consistent standardized
application command line protocol (parsing and validation) is
amazingly small, ... uh, make that tiny. <g>

The UNIX world does much better. Probably because they spend more time
in shells and getopt() is practically built-in.

-ralph

Tony Toews

4/13/2012 5:28:00 PM

0

On Thu, 12 Apr 2012 21:54:48 -0500, ralph <nt_consulting64@yahoo.net>
wrote:

>Yeah, we just had a thread a while back on that. Double quotes are
>only needed for shell parsers that use a space as a delimiter for
>commands and parameters.

Thanks, you and Karl might've just solved a problem a client reported
yesterday when trying to use a dashboard program with my utility.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

Karl E. Peterson

4/13/2012 8:09:00 PM

0

ralph explained on 4/12/2012 :
> Yeah, we just had a thread a while back on that. Double quotes are
> only needed for shell parsers that use a space as a delimiter for
> commands and parameters.

Don't think I saw that thread.

> Unfortunately since a program can never be quite sure how it is
> launched, or the means by which it is delivered, any 'strings'
> received from the outside world need to be tested for leading and
> trailing quotes.

Seems that way. And normal in all regards. At the moment, the damned
thing that's puzzling me is just how those quotes got past my parsing
routines in the first place! That's the trouble with code you wrote
decades ago. Heh...

--
..NET: It's About Trust!
http://vfre...

Karl E. Peterson

4/13/2012 8:22:00 PM

0

Mayayana formulated on Friday :
> I'm curious why you go to the trouble of API for
> that. Is there some advantage over s VB method
> like the following?
>
> Public Function FileExists(ByVal sPath As String) As Boolean
> Dim i As Integer
> On Error Resume Next
> i = GetAttr(sPath)
> If (Err = 0) Then
> If (i And vbDirectory) = 0 Then
> FileExists = True
> End If
> End If
> End Function

Well, I was about to say, "No", but it does offer some slight
advantage. There are files that GetAttr simply bombs on...

?fileexists("c:\pagefile.sys")
False

So if the routine needs to handle anything you throw at it, there's
really little choice.

Why these ones? I was interested in the full sweep of path-related
shell functions, as some of them seemed useful, and just threw together
a module that wraps nearly all of them. Now, this module gets added to
many projects for one reason or another, and at that point there's
little reason to go looking for (or just typing out) another FileExists
routine.

--
..NET: It's About Trust!
http://vfre...

ObiWan

4/17/2012 2:15:00 PM

0


> Seems that way. And normal in all regards. At the moment, the
> damned thing that's puzzling me is just how those quotes got past my
> parsing routines in the first place! That's the trouble with code
> you wrote decades ago. Heh...

well... add sFixedPath = Replace(sPath, Chr(34), "") before calling the
API and you should be quite ok... given that someone won't be so crazy
to use "special chars" for a folder name :D

Karl E. Peterson

4/17/2012 5:57:00 PM

0

ObiWan brought next idea :
>> Seems that way. And normal in all regards. At the moment, the
>> damned thing that's puzzling me is just how those quotes got past my
>> parsing routines in the first place! That's the trouble with code
>> you wrote decades ago. Heh...
>
> well... add sFixedPath = Replace(sPath, Chr(34), "") before calling the
> API and you should be quite ok... given that someone won't be so crazy
> to use "special chars" for a folder name :D

I dunno. I do agree that if the passed path is quoted on both ends,
it's probably prudent to strip them. But what if there's a quote in
the middle, or only on one end? I think it's a legit fail if the user
enters a malformed path, for example.

--
..NET: It's About Trust!
http://vfre...