Get Short Path Name without pinvoke?

[Steve Ricketts]

Is there a way to get the short path name of a file or directory without
using the GetShortPathName API call?

Thanks!

 

[Peter Duniho]

Is there a way to get the short path name of a file or directory without
using the GetShortPathName API call?

Not that I know of. The Directory.GetFiles() method has some particular
8.3-specific behavior that is called out in the docs (see
http://msdn.microsoft.com/en-us/library/wz42302f.aspx), but it still
returns the long filename. With some trickery and extra work, you can
probably design code to infer the short filename from the behavior of
the GetFiles() method, but that'd be a lot more work than just calling
the unmanaged API.

That said, it should be very rare that one would need to get the 8.3
filename. That's basically an implementation detail that a normal
application should never concern itself with (in fact, the fact that
GetFiles() is even affected by this is IMHO a bit of an API design flaw).

Pete

 

[Peter Duniho]

I've seen the underlying Windows FindFirstFile and FindNextFile APIs
also report the short names. I suspect the framework is simply using
those APIs.

Well, to be clear: the .NET API doesn't report the short filename. It's
just that a search may match a file based on the short filename (it will
still return the long filename).

And yes, the behavior is certainly because it's inherited from the
unmanaged API for which the .NET API is just a wrapper. But a) that
doesn't mean the original unmanaged API has the appropriate design (*),
and b) it doesn't mean that .NET should have just inherited the behavior.

Pete

(*) The unmanaged API evolved over a period of time when applications
actually may have had more reason to know both the short and long
filenames, and when there were plenty of applications that couldn't
handle anything but short filenames; backward compatibility being so
important in Microsoft's view, there's probably a good argument for the
unmanaged API being the way it is. But even there, we are well past the
point when a variant could have been added to the unmanaged API that
didn't have that funny behavior, and for sure there's no reason a
completely new API (i.e. .NET) needs it.

 

[Steve Ricketts]

Peter & Michael

Well, it's been such a long, long time ago that I ran into the problem I
can't remember how it went... something to do with a shell command and some
versions not accepting the quotes surrounding a long file name with spaces
and others taking it. Perhaps it was calling a program that couldn't use
the long file names. I ended up just converting everything I sent to a
shell to the short file name and it worked on all Windows versions. That
could even have been back in the old Windows 95 days, but like I said, I
can't really remember... only that it bit me in the behind a few times.

That said, it just seems logical that if the short file name still exists in
Windows, there should be a .Net way of getting it, no matter what the
reason... but what do I know?? ;-)

Thanks for the definitive answers though... I can move on accordingly and
that's a huge help.

Steve