What are the consequences, if any, of multiple backslashes in Windows paths?

Question

In my programs I frequently have file names and/or paths that are configured in my app.config file. This will usually be something like:

<add key="LogFileDirectory" value="C:\Logs" />
<add key="SaveLogFileTo" value="MyLogFile.txt" />

In my actual application code, I'll frequently concatenate these together with code similar to this:

var logFile = ConfigurationManager.AppSettings["LogFileDirectory"]
+ @"\" +
ConfigurationManager.AppSettings["SaveLogFileTo"];

Now, the result of the above code would give a log file path of C:\Logs\MyLogFile.txt, however, if the end-user specifies the log file directory in the configuration file as C:\Logs\ with a trailing backslash, my code results in an actual path of C:\Logs\\MyLogFile.txt with a double backslash between the directory and the file.

In my experience, this works just fine in practice. As a matter of fact, even dropping to a command prompt and executing cd c:\\\\\\windows\\\ works in practice.

My question is, what, if any, are the consequences of having paths like this? I don't want to be using this "feature" in production code if it is something that is undocumented and subject to be broken at some point in the future with a new release of Windows.

Broyles

Have you ever heard of the Path class and in particular of the Path.Combine method? – Prostate

If you are worried about wrong concatenation, try using System.IO.Path.Combine. – Fluke

Yes, thank you, I have some familiarity with that method, although don't use it much in practice. I'm more interested in the theory behind multiple backslashes seeming to work without issue and whether or not this is an intentional, documented feature. – Broyles

then why don't you add the double slashes in the filepath in the config file as well as the single trailing "\" or use the string literal @ in front of the logfile like this declare the logfile like this at the class level private static string logfile { get; set; } then assign logFile as like this @logFile = var logFile = ConfigurationManager.AppSettings["LogFileDirectory"] etc... – Vineland

Perhaps this would help – Hepplewhite

check this SO Question --> #22568285 Also this SO Question --> #10161677 – Swadeshi

Double backslashes are not permitted in long paths, i.e., paths beginning with \\?\ – Polygon

Answer 1

There are no consequences that I know of, and it's not likely to be broken in future versions, because a lot of people will be doing the same as you.

However, the correct way to combine paths in C# is to use Path.Combine, which will remove any extra backslashes for you:

var logFile = Path.Combine(
    ConfigurationManager.AppSettings["LogFileDirectory"],
    ConfigurationManager.AppSettings["SaveLogFileTo"]);

Peignoir

One thing to be careful of Path.Combine (which bit me today in another answer), from the remarks on the msdn "If path2 does not include a root (for example, if path2 does not start with a separator character or a drive specification), the result is a concatenation of the two paths, with an intervening separator character. If path2 includes a root, path2 is returned." – Marchese

Answer 2

At least these kind of consequences there are:

del command cannot delete the file if you provide two backslashes after the drive letter and colon:

C:\>del c:\\foo.txt
The filename, directory name, or volume label syntax is incorrect.

C:\>del c:\\bar\foo.txt
The network path was not found.

I mean, according to my experiments, the cmd.exe built in "del" command has a bug that tries to access a network share instead.

The bug is dangerous actually. The del command believes that c:\\bar\foo\zap.txt means \\bar\foo\zap.txt and if there really is a server "bar" that has share "foo" that has file "zap.txt", an incorrect file will be deleted if you meant a local file c:\bar\foo\zap.txt instead.

I do not know that other commands would behave this way. For example the built in type and copy commands ignore the duplicate backslash and refer to local file.

Biggers

Please add an explanation to your code, so that other can also understand. – Ohare