DOS Short Names

[CapCity]

If I have a strig that represents a path, how can I programmatically get the
"short" DOS name for it?

For example, if I have "C:\Program Files\" I want "C:\Progra~1\".

Thanks

 

[Larry Smith]

If I have a strig that represents a path, how can I programmatically get

the "short" DOS name for it?

For example, if I have "C:\Program Files\" I want "C:\Progra~1\".

AFAIK, there's no native .NET function to do this. You can simply rely on
"GetShortPathName()" in the WinAPI assuming your app is targetted for
Windows (and which .NET app isn't). Here's the first example when I googled
for "C#" and "GetShortPathName()" (many more exist)

http://www.pinvoke.net/default.aspx/kernel32.GetShortPathName

 

[Guest]

Cheat

public string FakeDosFileString(string myStr)
string[] myChildren = myStr.split(new char[] {'\\'});
string Answer = "";

for(int x = 0; x < myChildren.length; x++ )
{
if (myChildren[x].length > 8)
myChildren[x] = myChildren[x].substring(0,6) + @"~1";
Answer += myChildren[x] + "\\";
}
return Answer;
}

I didnt run this through the compliler yet....
Hope the fixes you prob.

 

[Robson Siqueira]

TheMadHatter,

Man, don't get me wrong. but sometimes we have ~2, ~3, numbers, etc. I don't
think that would work for everything.

I've found a pretty interesting article on the internet.
http://www.c-sharpcorner.com/Upload...rticleID=63e02c1f-761f-44ab-90dd-8d2348b8c6d2



--
Regards,
Robson Siqueira
Enterprise Architect

Cheat

public string FakeDosFileString(string myStr)
string[] myChildren = myStr.split(new char[] {'\\'});
string Answer = "";

for(int x = 0; x < myChildren.length; x++ )
{
if (myChildren[x].length > 8)
myChildren[x] = myChildren[x].substring(0,6) + @"~1";
Answer += myChildren[x] + "\\";
}
return Answer;
}

I didnt run this through the compliler yet....
Hope the fixes you prob.

If I have a strig that represents a path, how can I programmatically get
the
"short" DOS name for it?

For example, if I have "C:\Program Files\" I want "C:\Progra~1\".

Thanks

 

[Larry Smith]

public string FakeDosFileString(string myStr)

string[] myChildren = myStr.split(new char[] {'\\'});
string Answer = "";

for(int x = 0; x < myChildren.length; x++ )
{
if (myChildren[x].length > 8)
myChildren[x] = myChildren[x].substring(0,6) + @"~1";
Answer += myChildren[x] + "\\";
}
return Answer;
}

I didnt run this through the compliler yet....
Hope the fixes you prob.

You can't assume the tilde character will be in use but in any case, it's
always safer to rely on the official version of any function.

 

[Guest]

True, very true, hence why I called it a cheat.

The conditions of the program I wrote was a string input, returning a string
output.
Under that condition, it should work *cough* correctly.
(except the fact that I forgot one "{" )

TheMadHatter,

Man, don't get me wrong. but sometimes we have ~2, ~3, numbers, etc. I don't
think that would work for everything.

I've found a pretty interesting article on the internet.
http://www.c-sharpcorner.com/Upload...rticleID=63e02c1f-761f-44ab-90dd-8d2348b8c6d2



--
Regards,
Robson Siqueira
Enterprise Architect

Cheat

public string FakeDosFileString(string myStr)
string[] myChildren = myStr.split(new char[] {'\\'});
string Answer = "";

for(int x = 0; x < myChildren.length; x++ )
{
if (myChildren[x].length > 8)
myChildren[x] = myChildren[x].substring(0,6) + @"~1";
Answer += myChildren[x] + "\\";
}
return Answer;
}

I didnt run this through the compliler yet....
Hope the fixes you prob.

If I have a strig that represents a path, how can I programmatically get
the
"short" DOS name for it?

For example, if I have "C:\Program Files\" I want "C:\Progra~1\".

Thanks

 

[Guest]

Probably the best idea would be to use Robson's idea,
except for one modification:

[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError=true)]
static extern uint GetShortPathName(
[MarshalAs(UnmanagedType.LPTStr)]
string lpszLongPath,
[MarshalAs(UnmanagedType.LPTStr)]
StringBuilder lpszShortPath,
uint cchBuffer);

That way you can get the short name instead of the other way around.
*Sigh* Where would the world be with out Pinvokes. (www.pinvoke.net)

public string FakeDosFileString(string myStr)
string[] myChildren = myStr.split(new char[] {'\\'});
string Answer = "";

for(int x = 0; x < myChildren.length; x++ )
{
if (myChildren[x].length > 8)
myChildren[x] = myChildren[x].substring(0,6) + @"~1";
Answer += myChildren[x] + "\\";
}
return Answer;
}

I didnt run this through the compliler yet....
Hope the fixes you prob.

You can't assume the tilde character will be in use but in any case, it's
always safer to rely on the official version of any function.

 

[Larry Smith]

That way you can get the short name instead of the other way around.

*Sigh* Where would the world be with out Pinvokes. (www.pinvoke.net)

I think I was already first out of the block to point that out. However, the
WinAPI version requires that the file already exists on disk (stupid).
ERROR_FILE_NOT_FOUND will be returned otherwise. I wrote a (C++) wrapper a
number of years ago that provides an option to create a temporary file first
if the file doesn't already exist (which is still problemati if you don't
have write access to the folder). "GetShortPathName()" will then succeed and
you can kill the temporary. A hack of course but what more can you do.

 

[Guest]

Probably the real q is why one would want the old dos way anyhow.

Why would you go to the trouble of getting the dos format
of a file and directory that doesnt exist?

 

[Larry Smith]

Probably the real q is why one would want the old dos way anyhow.

Because the format's still supported on Windows and there are countless
legacy applications that still deal with it (try chaniging directories from
the command prompt using a short name for instance and watch what happens to
the prompt). I just recently left a very large and well-known company for
instance and they're using a major package from another large and well-known
company that still has 8.3 issues which I had to deal with on occasion. The
format's still out there IOW but unless you're a grizzled programming vet
from the 80s and 90s (since they're the ones with the know-how to deal with
the older technology), you probably won't see it much. I'm one of the older
ones who does from time-to-time.

Why would you go to the trouble of getting the dos format
of a file and directory that doesnt exist?

For the same reasons you'ld retrieve the file name for any file that doesn't
exist. A file's a file regardless of its naming convention (8.3 or not) so
you may have to deal with it even before it exists (if only to check its
existence, create it from scrach, or whatever).

 

[Mike Schilling]

I think I was already first out of the block to point that out. However,
the WinAPI version requires that the file already exists on disk (stupid).

No, it's quite right. If the file doesn't exist, then ERROR_FILE_NOT_FOUND
(or some other error code) is appropriate, because the question can't be
answered.

ERROR_FILE_NOT_FOUND will be returned otherwise. I wrote a (C++) wrapper a
number of years ago that provides an option to create a temporary file
first if the file doesn't already exist (which is still problemati if you
don't have write access to the folder). "GetShortPathName()" will then
succeed and you can kill the temporary. A hack of course but what more can
you do.

But that doesn't make sense. The value of the 8.3 name depends on what
files already exist in the directory. "Program Files" usually turns into
PROGRA~1, but if there's already, say, a "Program Loader", it would be
PROGRA~1, and "Program Files" would become PROGRA~2. There's no guarantee
that your temporary file would have the same 8.3 name as another file of the
same long name that gets created at another time. (What would be safe is to
create the temp file with some marker that says it's OK for the real file to
overwrite it. Not necessarily possible with a third-party app, I know)

 

[Larry Smith]

That way you can get the short name instead of the other way around.

No, it's quite right. If the file doesn't exist, then
ERROR_FILE_NOT_FOUND (or some other error code) is appropriate, because
the question can't be answered.


But that doesn't make sense. The value of the 8.3 name depends on what
files already exist in the directory. "Program Files" usually turns into
PROGRA~1, but if there's already, say, a "Program Loader", it would be
PROGRA~1, and "Program Files" would become PROGRA~2. There's no guarantee
that your temporary file would have the same 8.3 name as another file of
the same long name that gets created at another time. (What would be safe
is to create the temp file with some marker that says it's OK for the real
file to overwrite it. Not necessarily possible with a third-party app, I
know)

You're missing the point. I simply want to pass "C:\Program Files\Whatever"
to a function that will return "C:\Progra~2\Whatever" even though "Whatever"
doesn't exist yet. "GetShortPathName()" will therefore fail so the
work-around is to give it what it wants. Create "C:\Program Files\Whatever"
first, pass it to "GetShortPathName()" and then remove it. It's that simple.
The real issue is that the OS can give me the short name at the time I ask
for it even though it doesn't physically exist yet. Just tell me what the
short name would be if I created it right now. What I do with it afterwards
is not its concern.

 

[Mike Schilling]

You're missing the point. I simply want to pass "C:\Program
Files\Whatever" to a function that will return "C:\Progra~2\Whatever" even
though "Whatever" doesn't exist yet. "GetShortPathName()" will therefore
fail so the work-around is to give it what it wants. Create "C:\Program
Files\Whatever" first, pass it to "GetShortPathName()" and then remove it.
It's that simple.

It's simpler still to do a bit of parsing and chop off anything past the
last segment that needs conversion. The OS is happy to tell you the short
name for "C:\Program Files", and there's no need for you to create a temp
file or worry about read-only directories.

 

[Larry Smith]

It's simpler still to do a bit of parsing and chop off anything past the

last segment that needs conversion. The OS is happy to tell you the short
name for "C:\Program Files", and there's no need for you to create a temp
file or worry about read-only directories.

It shouldn't be necessary to muck around with this stuff if
"GetShortPathName()" was doing its job correctly. That's the point.
Moreover, you're not dealing with a simple parse. You need to deal with
paths that may physically exist up to the nth subfolder only (requiring an
iterative check of some sort), paths that aren't fully-qualified, etc. The
tilde character is also not guaranteed on all systems and MSFT states that
you shouldn't rely on it as I recall (though it's been a long time).
Guessing exactly how the shortname is created under all circumstances is
also unreliable. I may be naive to assume MSFT's algorithm always follows
the accepted convention of "AAAAAA~#". It might not and/or there may be
issues you and I aren't aware of (noting that file names have elaborate
rules that may impact the outcome). It's simply safer and easier to rely on
the OS.

 

[Mike Schilling]

It shouldn't be necessary to muck around with this stuff if
"GetShortPathName()" was doing its job correctly.

But it is. It's telling you the correct name when it's known, and refusing
to do so when it can't be calculated.

That's the point. Moreover, you're not dealing with a simple parse.

Sure you are. Components in the path are separated by either "/" or "\",
and the legal 8.3 characters are well-defined. Remove everything after the
last component that needs to be translated. If you don't get an answer from
that, it's because the answer isn't known.

In other words, if you want to translate C:\Program Files\a\b\c\d\e, ask for
C:\Program Files and tack a\b\c\d\e onto the answer. If you don't get an
answer, C:\Program Files doesn't exist, and you can't really be sure what
its 8.3 name will be when it's created.

You need to deal with paths that may physically exist up to the nth
subfolder only (requiring an iterative check of some sort),

The OS call does that check for you

paths that aren't fully-qualified, etc.

I don't see why that matters.

The tilde character is also not guaranteed on all systems and MSFT states
that you shouldn't rely on it as I recall (though it's been a long time).

If I were MSFT, I'd say the same thing. No point making guarantees you
might have to break.

Guessing exactly how the shortname is created under all circumstances is
also unreliable. I may be naive to assume MSFT's algorithm always follows
the accepted convention of "AAAAAA~#". It might not and/or there may be
issues you and I aren't aware of (noting that file names have elaborate
rules that may impact the outcome). It's simply safer and easier to rely
on the OS.

Agreed. I'm not proposing you do otherwise. The only assumptions you need
to make are about the use of ":", "/", and "\", and that should be safe.