I am quite surprised at the fact that Path.Combine("c:\abc", "\def") produces \def (not c:\abc\def).
See this feedback:
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx feedbackid=bde653a2-7588-4145-89d1-54c1958f1a05
I don't quite understand the reasons behind this 'intentional behavior'. For security I can't think of any reason...
Please enlight me!
Path.Combine problem
Hot Topic
- How do you Modify a node name?
- Storing/Retrieving Various File Formats in DB Application
- Problem accessing Connection String in code-behind
- Error in MS VS.NET 2005 TEAM Message: Context 0x1b1670' is disconnected.
- MCST Certification
- again
- Loading application efficiently
- ADO.NET corrupting SQL parameters
- Filtering Illegal Characters from Dynamic Query for MS Access
- Is it possible to manually control the assembly version numbers when creating & building a class library?
.NET Development
- Inserting large amount of rows using ADO.NET
- VB.Net 2003 Asynchronous Socket Problem
- Re-using Model-View-Controller architecture between WinForms and Web Forms
- How to send SMS?
- Removing a Relationship in a Microsoft Access Database
- BeginSend()
- XmlSerializer deadlock/timeout in .NET 2.0
- What happened to ValidateAll() from VS 2005 Beta 1?
- delete first row in CSV file
- Paging Nested DataList
Path.Combine problem
RyanAustin
Well, I have had absolutely no part in the design of the this API, but:
to me the current behavior make more sense to me than what you expect. My mental picture of what's happening here is that you start of by going to the end of the first argument and then continue down (or up) as specified in the second argument.
I would *not* have expected Path.Combine("\abc", "\def") to be equivalent to Path.Combine("\abc", "def") - "\def" and "def" are different paths...
Another issue with doing what you suggest is what Path.Combine("C:\abc", "D:\def") should return
Now, I would also be more than willing to accept an InvalidArgumentException to be thrown if the second path was an absolute path, so I don't say that the current interpretation is The One And Only Interpretation of what should (or shouldn't) happen...
And I don't think that your interpretation is totally unreasonable either - I just think that the current behavior is a tad more logical.
Best regards,
Johan Stenberg
buckeye72
You can add a suggestion here: http://lab.msdn.microsoft.com/productfeedback/
This way, the request should end up at the team that actually own the Path API:s - they should be able to give you a better answer as to if this will be considered or not.
Best regards,
Johan Stenberg
doublezen
And I don't think that dot-dot thing is related to my problem... Sorry.
mdavison
Suppose I get the second part from somewhere that I cannot control if it is prefixed with \. I have to check if it is prefixed with \ - though this is very easy, but it is tedious and repetive work.
vbuser1
I would check out the Path.GetPathRoot. That should help you cover the "C:\abc" case as well as the "\abc" case... and then create my own Path.AppendPath that did the check once and for all and just call this method. This way you only have to write it once, and hopefully it won't be too hard to switch to this "new" api in your code...
And depending on what you are going to do with the path, you may want to take a second look to make sure that no-one can use it to attack your system. Simple tricks like the good old dot-dot (up one) in the directory path can cause your app to "escape" from where it is supposed to be reading/writing...
Best regards,
Johan Stenberg