Microsoft still does not understand file paths. (strDrive & strDirectory & "\" & strFilename is INCO

[BoonHead, The Lost Philosopher]

I think the .NET framework is great!

It's nice, clean and logical; in contradiction to the old Microsoft.



It only saddens me that the new Microsoft still doesn't under stand there own rules when it comes to file paths.

A lot of Microsoft installers for example, and also installers of other companies, do not work because they handle paths in the following manner:



strPath = strDrive & strDirectory & "\" & strFile = "C:" & "\WrongDirectoryWithoutSlash" & "\" & "Filename.ext" = "C:\WrongDirectoryWithoutSlash\Filename.ext"

This seems correct...but it is not.

What happened if the directory is the root directory?

Or what if the directory is a correct directory?

Look at the following:



strPath = strDrive & strDirectory & "\" & strFile = "C:" & "\" & "\" & "Filename.ext" = "C:\\Filename.ext"
strPath = strDrive & strDirectory & "\" & strFile = "C:" & "\CorrectDirectoryEndingWithASlash\" & "\" & "Filename.ext" = "C:\CorrectDirectoryEndingWithASlash\\Filename.ext"

The result is a path with double slashes...and therefore wrong...

A directory not ending with a slash is by definition a file.

A file ending with a slash is by definition a directory.

The difference between the directory named "bla" and the file named "bla" is the slash.

That's how programs know the difference. (Copy, "Is the destination a file or a directory?")


Dear Microsoft,



If you do not understand something as simple as file locations...

(You know..."file locations"...the most important thing...were it all begins...)

....then what must become of you?

Would you please fix this VERY OLD, PRETTY IMPORTANT BUG?



BTW- I loved your writing about software quality (http://docs.msdnaa.net/ark_new3.0/cd3/content/Books\Academico\Microsoft course - Chapter 2.doc)



Yours,



BoonHead, The Lost Philosopher



I'm not that good in putting it into words.

Actualy I'm pretty bad in putting this into words.

But does anyone understand this problem and does anyone agee or disagree with me?

 

[Leon Jollans]

Hi Boonhead.
You're wrong about the slash. The difference between a file and a directory
is not the slash. A directory is a file with the directory flag set.

This is how the file system knows. it takes a file, checks the directory
flag, and treats it accordingly.

Have a look at unix file attributes for confirmation of this, you have flags
for Read,Write and Execute permissions for Users,Groups and Others, and a
directory flag. eg rw-r--r--d (please don't pull me up on the suitability of
this permission set btw ) )

Your problem is passing a directory name with a trailing slash. Well as you
can see, you are labouring under a misapprension, and creating your own
problem.

Can I suggest, that if you need to pass a directory name to a string
formatter that appends its own trailing slash, that you check the string
first for a trailing slash manually and remove it. Not a tricky bit of code:

if Right( strDirectory, 1 ) = "\" Then strDirectory = Left(strDirectory,
strDirectory.Length-1 )

hope this helps,

Leon



I think the .NET framework is great!
It's nice, clean and logical; in contradiction to the old Microsoft.

It only saddens me that the new Microsoft still doesn't under stand there
own rules when it comes to file paths.
A lot of Microsoft installers for example, and also installers of other
companies, do not work because they handle paths in the following manner:

strPath = strDrive & strDirectory & "\" & strFile = "C:" &
"\WrongDirectoryWithoutSlash" & "\" & "Filename.ext" =
"C:\WrongDirectoryWithoutSlash\Filename.ext"

This seems correct...but it is not.
What happened if the directory is the root directory?
Or what if the directory is a correct directory?
Look at the following:

strPath = strDrive & strDirectory & "\" & strFile = "C:" & "\" & "\" &
"Filename.ext" = "C:\\Filename.ext"
strPath = strDrive & strDirectory & "\" & strFile = "C:" &
"\CorrectDirectoryEndingWithASlash\" & "\" & "Filename.ext" =
"C:\CorrectDirectoryEndingWithASlash\\Filename.ext"

The result is a path with double slashes...and therefore wrong...
A directory not ending with a slash is by definition a file.
A file ending with a slash is by definition a directory.
The difference between the directory named "bla" and the file named "bla" is
the slash.
That's how programs know the difference. (Copy, "Is the destination a file
or a directory?")

Dear Microsoft,

If you do not understand something as simple as file locations...
(You know..."file locations"...the most important thing...were it all
begins...)
....then what must become of you?
Would you please fix this VERY OLD, PRETTY IMPORTANT BUG?

BTW- I loved your writing about software quality
(http://docs.msdnaa.net/ark_new3.0/cd3/content/Books\Academico\Microsoft
%20course%20-%20Chapter%202.doc)

Yours,

BoonHead, The Lost Philosopher

I'm not that good in putting it into words.
Actualy I'm pretty bad in putting this into words.
But does anyone understand this problem and does anyone agee or disagree
with me?

 

[BoonHead, The Lost Philosopher]

Dear Lean,

I usualy have something as this function in my programs:

Function CorrectPath(strPath) As String
'I hope it's just a directory name that has been send as a
parameter...Sometimes you have no way of knowing...
If strPath.Length > 0 Then
Select Case Right(strPath, 1)
Case "\", "/"
Return strPath
Case Else
Return strPath & "/"
End Select
End If
End Function

But that's not the point...

I know how the FAT/DET works but I wasn't refering to the physical part of
files and directories.
I was refering to the textual part; paths.

What if do this?:
C:\>Copy "*.*" "NewName2"
How do you read the directory attribute of a non-existing "object"
(directory or file).
And this is just one lame example...there are better ones.

Unix is a lot better. Unix usualy has nice and correct textual paths.
Hell, I even saw slashes behind every directory name in the file browser in
a Linux distribution once ("bin/")

So...
What if the directory/file doesn't exist? What if a path had no physical
object?
Pure textual...Directories without a slash are wrong and cause a lot of bugs
if the programmer doesn't incalculate the illogicalness. (And I mean "A LOT
OF BUGS")
Programs and liberaries programmed by a good programmer always have the
standard "try-to-correct-illogicalness"-code which is a waste of bytes and
time.

Yours,

BoonHead

 

[Jon Skeet]

What if the directory/file doesn't exist? What if a path had no physical
object?

Then it's neither a regular file nor a directory, is it? Whether it
should be created as a directory or a file is up to the semantics of
the application in question.

Pure textual...Directories without a slash are wrong

Care to provide any documentation to "prove" this? It's not the way
I've ever worked - I've just kept a strict distinction between when
things should be files and when they should be directories.

 

[Leon Jollans]

I'm not sure I follow under which circumstances this is a problem. if it's
bad user input then you'll need to parse it anyway.

The DOS copy command recognises an existing file or directory with no
problem, but if it doesn't exist how could it know whether to create a file
or a directory? There'd have to be some interesting heuristics in place to
achieve it, but besides that you wouldn't want it to second guess you
anyway. There's not much more frustrating than software that decides it
knows what you want without asking you. Admittedly it might be useful to
have a copy -d flag that creates the source string as a directory but XCopy
will reproduce a directory tree if that's what you want.

Ultimately it's a question of semantics. If you're enumerating files, what's
the real cost of checking the directory bit versus looking for a trailing
slash? Or if it's user friendliness you want, dir will tell you if the
file's a directory by writing a big <DIR> next to the name.

If I understand you, you want to ascertain whether a file is a directory in
code based on whether it ends in a slash. Would you have it end in "/R" if
it was read only too? of course not. So I don't see the problem.

Regards,

Leon

 

[BoonHead, The Lost Philosopher]

Damn, sorry for misspelling your name Leon.

The DOS copy command recognises an existing file or directory with no
problem, but if it doesn't exist how could it know whether to create a file
or a directory? There'd have to be some interesting heuristics in place to
achieve it, but besides that you wouldn't want it to second guess you
anyway. There's not much more frustrating than software that decides it
knows what you want without asking you.
TRUE

Admittedly it might be useful to
have a copy -d flag that creates the source string as a directory but XCopy
will reproduce a directory tree if that's what you want.

But why al the programming fuz and program a -d flag when the slash saids it all?
And why not have a root directory with out an ending slash? (which is also it's starting slash)
(Just like you...I know why not...just a hypo-question...)

Should time-critical components constantly filter each others output?

Let me ask you a question...aside the issue of correct/incorrect paths...
What do you think of 75% of installers, Microsofts and non-Microsoft, that fail when supplier with a path ending with a slash?

I just think it just doesn't seem consistant.
And that when we are talking about software systems...

Ultimately it's a question of semantics. If you're enumerating files, what's
the real cost of checking the directory bit versus looking for a trailing
slash? Or if it's user friendliness you want, dir will tell you if the
file's a directory by writing a big <DIR> next to the name.

A name isn't a path. The Linux file browser example was just related but slashes in the file browser is not nessisary. It just suprised me.

If I understand you, you want to ascertain whether a file is a directory in
code based on whether it ends in a slash. Would you have it end in "/R" if
it was read only too? of course not. So I don't see the problem.

Attributes are, in anyway, not part of a path.

 

[Leon Jollans]

Let me ask you a question...aside the issue of correct/incorrect paths...
What do you think of 75% of installers, Microsofts and non-Microsoft, that fail when supplier with a path ending with a slash?

Don't supply a path ending with a slash then ;o)

Seriously though, isn't that the fault of the installer, rather than Microsoft per sé

Leon

 

[Jay B. Harlow [MVP - Outlook]]

BoonHead,
Have you looked at System.IO.Path.Combine function? Its a .NET class that
applies consistent formatting for paths.

Instead of :

strPath = strDrive & strDirectory & "\" & strFile = "C:" &
"\WrongDirectoryWithoutSlash" & "\" & "Filename.ext" =
"C:\WrongDirectoryWithoutSlash\Filename.ext"

Use:

Imports System.IO

Dim drive As String = "C:"
Dim directory As String = "\WrongDirectoryWithoutSlash"
Dim file As String = "Filename.ext"
Dim path As String

path = Path.Combine(drive, directory)
path = Path.Combine(path, file)

Which does have an interesting side effect, the drive is dropped as
directory is 'rooted', if you apply:

directory = directory.Trim(Path.DirectorySeparatorChar,
Path.AltDirectorySeperatorChar)

Before the first Path.Combine then you have the desired effect. However I
noticed that it creates a relative path to C: not out of the root... Hmm...

Either way I would suggest you use Path.Combine over string concatenation,
as the Path.Combine has set rules for combining paths, where as String
concatenation gives you what you put in.

Hope this helps
Jay

I think the .NET framework is great!

It's nice, clean and logical; in contradiction to the old Microsoft.



It only saddens me that the new Microsoft still doesn't under stand there
own rules when it comes to file paths.

A lot of Microsoft installers for example, and also installers of other
companies, do not work because they handle paths in the following manner:



strPath = strDrive & strDirectory & "\" & strFile = "C:" &
"\WrongDirectoryWithoutSlash" & "\" & "Filename.ext" =
"C:\WrongDirectoryWithoutSlash\Filename.ext"

This seems correct...but it is not.

What happened if the directory is the root directory?

Or what if the directory is a correct directory?

Look at the following:



strPath = strDrive & strDirectory & "\" & strFile = "C:" & "\" & "\" &
"Filename.ext" = "C:\\Filename.ext"
strPath = strDrive & strDirectory & "\" & strFile = "C:" &
"\CorrectDirectoryEndingWithASlash\" & "\" & "Filename.ext" =
"C:\CorrectDirectoryEndingWithASlash\\Filename.ext"

The result is a path with double slashes...and therefore wrong...

A directory not ending with a slash is by definition a file.

A file ending with a slash is by definition a directory.

The difference between the directory named "bla" and the file named "bla" is
the slash.

That's how programs know the difference. (Copy, "Is the destination a file
or a directory?")


Dear Microsoft,



If you do not understand something as simple as file locations...

(You know..."file locations"...the most important thing...were it all
begins...)

....then what must become of you?

Would you please fix this VERY OLD, PRETTY IMPORTANT BUG?



BTW- I loved your writing about software quality
(http://docs.msdnaa.net/ark_new3.0/cd3/content/Books\Academico\Microsoft
%20course%20-%20Chapter%202.doc)



Yours,



BoonHead, The Lost Philosopher



I'm not that good in putting it into words.

Actualy I'm pretty bad in putting this into words.

But does anyone understand this problem and does anyone agee or disagree
with me?

 

[BoonHead, The Lost Philosopher]

Dear Jay,

Yes, I have seen the path combine function.
Still I would like to thank you for your tip.
(I think this function is better than nothing.)

Yours,

BoonHead.

 

[BoonHead, The Lost Philosopher]

Dear Leon,

Don't supply a path ending with a slash then ;o)

I was not refering to me.

Seriously though, isn't that the fault of the installer, rather than Microsoft per sé

I don't understand...The installer is Microsoft's...

But okey...Let say that you are right...
(Don't get me wrong: I think you just as easely could be right.)
Let say Directory paths without a slash is normal.

Should we not set a new standard?
Paths ending with a slash is logical.
....no more fuz-code...


Let me ask you a question...aside the issue of correct/incorrect paths...
What do you think of 75% of installers, Microsofts and non-Microsoft, that fail when supplier with a path ending with a slash?

Don't supply a path ending with a slash then ;o)

Seriously though, isn't that the fault of the installer, rather than Microsoft per sé

Leon

 

[Leon Jollans]

Should we not set a new standard?

Paths ending with a slash is logical.

Although I've never had a problem with what you describe, I do agree with you that making an explicit distinction at all times would be more readable. Then again the .NET Framework Directory and File classes do abstract this distinction for you if you program to them rather than digging down directly to the FS itself. Personally I'd rather not have to use explicit paths in my code at all if I can avoid it ;o)

regards,

Leon

Don't supply a path ending with a slash then ;o)

I was not refering to me.

Seriously though, isn't that the fault of the installer, rather than Microsoft per sé

I don't understand...The installer is Microsoft's...

But okey...Let say that you are right...
(Don't get me wrong: I think you just as easely could be right.)
Let say Directory paths without a slash is normal.

Should we not set a new standard?
Paths ending with a slash is logical.
...no more fuz-code...


Let me ask you a question...aside the issue of correct/incorrect paths...
What do you think of 75% of installers, Microsofts and non-Microsoft, that fail when supplier with a path ending with a slash?

Don't supply a path ending with a slash then ;o)

Seriously though, isn't that the fault of the installer, rather than Microsoft per sé

Leon

 

[Andy Fish]

IMHO this is all the fault of the operating system and is caused by
ambiguity on the syntax windows uses to specify file and directory names. in
VMS you would say

c:[progam files.myapp]myapp.exe

which is completely unambiguous. to refer to a directory you say

c:[progam files.myapp]

and if you explicitly want to access a directory as a file you could say

c:[program files]myapp

I presume this is one of the features from dos that was "inspired by" unix
and it was a careless mistake to copy it. Far worse was copying the unix
idea of a 'path' variable but that's another story.

Should we not set a new standard?
Paths ending with a slash is logical.

Although I've never had a problem with what you describe, I do agree with
you that making an explicit distinction at all times would be more readable.
Then again the .NET Framework Directory and File classes do abstract this
distinction for you if you program to them rather than digging down directly
to the FS itself. Personally I'd rather not have to use explicit paths in my
code at all if I can avoid it ;o)

regards,

Leon

message Dear Leon,

Don't supply a path ending with a slash then ;o)

I was not refering to me.

Seriously though, isn't that the fault of the installer, rather than

Microsoft per sé
I don't understand...The installer is Microsoft's...

But okey...Let say that you are right...
(Don't get me wrong: I think you just as easely could be right.)
Let say Directory paths without a slash is normal.

Should we not set a new standard?
Paths ending with a slash is logical.
....no more fuz-code...


Let me ask you a question...aside the issue of correct/incorrect paths...
What do you think of 75% of installers, Microsofts and non-Microsoft, that
fail when supplier with a path ending with a slash?

Don't supply a path ending with a slash then ;o)

Seriously though, isn't that the fault of the installer, rather than
Microsoft per sé

Leon