Directory.GetFiles oddity.
-
Something I discovered today, while in general
Directory.GetFiles()doesn't need a terminating slash in the path in the specific case of the root directory on a drive it does. "C:\blah" works fine; "C:\" works fine "C:" returns zero results even if the files exist. I suppose this could be argued as a gray area but it doesn't appear to be documented in MSDN, and if it's being considered an illegal path it should throw an exception instead of failing silently. It was easy to find once I fired up the debugger, but I'd've never expected it to be a problem until I got the bug report...Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Something I discovered today, while in general
Directory.GetFiles()doesn't need a terminating slash in the path in the specific case of the root directory on a drive it does. "C:\blah" works fine; "C:\" works fine "C:" returns zero results even if the files exist. I suppose this could be argued as a gray area but it doesn't appear to be documented in MSDN, and if it's being considered an illegal path it should throw an exception instead of failing silently. It was easy to find once I fired up the debugger, but I'd've never expected it to be a problem until I got the bug report...Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
I agree with you that it shouldn't behave that way but there is a certain amount of logic to it: C: is a DRIVE C:\ is a FOLDER C:\blah may be a FOLDER or a FILE but it can tell by looking C:\blah\ is expected to refer to a FOLDER
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
Something I discovered today, while in general
Directory.GetFiles()doesn't need a terminating slash in the path in the specific case of the root directory on a drive it does. "C:\blah" works fine; "C:\" works fine "C:" returns zero results even if the files exist. I suppose this could be argued as a gray area but it doesn't appear to be documented in MSDN, and if it's being considered an illegal path it should throw an exception instead of failing silently. It was easy to find once I fired up the debugger, but I'd've never expected it to be a problem until I got the bug report...Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
DOS-style file specifications suc... ceed at causing all sorts of trouble. (And don't get me started on file names containing SPACEs :mad: ) OpenVMS rules!!
-
I agree with you that it shouldn't behave that way but there is a certain amount of logic to it: C: is a DRIVE C:\ is a FOLDER C:\blah may be a FOLDER or a FILE but it can tell by looking C:\blah\ is expected to refer to a FOLDER
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
If it threw a
NotADirectorExceptionI'd be at most mildly annoyed with the implementation, the silent failure is the real problem.Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
If it threw a
NotADirectorExceptionI'd be at most mildly annoyed with the implementation, the silent failure is the real problem.Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
If it threw a
NotADirectorExceptionI'd be at most mildly annoyed with the implementation, the silent failure is the real problem.Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
dan neely wrote:
the silent failure is the real problem.
That's the bad part. You'd think someone would just have it throw an exception so you could at least do something when that happens.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
Something I discovered today, while in general
Directory.GetFiles()doesn't need a terminating slash in the path in the specific case of the root directory on a drive it does. "C:\blah" works fine; "C:\" works fine "C:" returns zero results even if the files exist. I suppose this could be argued as a gray area but it doesn't appear to be documented in MSDN, and if it's being considered an illegal path it should throw an exception instead of failing silently. It was easy to find once I fired up the debugger, but I'd've never expected it to be a problem until I got the bug report...Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
The result of Directory.GetFiles("c:") is well defined. You get the same result as if you typed "dir c:" from a command prompt. The result is the contents of the current directory on the c drive. The result of Directory.GetFiles(@"c:\") is the contents of the root directory. If you leave off the '\', Directory.GetFiles() will return a relative path to the current directory on the specified drive. So, Directory.GetFiles(@"c:\blah") is the contents of the blah directory off of the root and Directory.GetFiles(@"c:blah") is the contents of the blah directory off of the current directory on the c drive. If you leave off the drive, Directory.GetFiles() will return either an absolute or relative path on the current drive. So, Directory.GetFiles(@"\blah") is the contents of the blah directory on the current drive and Directory.GetFiles(@"blah") is the contents of the blah directory off of the current directory of the current drive.
-
Something I discovered today, while in general
Directory.GetFiles()doesn't need a terminating slash in the path in the specific case of the root directory on a drive it does. "C:\blah" works fine; "C:\" works fine "C:" returns zero results even if the files exist. I suppose this could be argued as a gray area but it doesn't appear to be documented in MSDN, and if it's being considered an illegal path it should throw an exception instead of failing silently. It was easy to find once I fired up the debugger, but I'd've never expected it to be a problem until I got the bug report...Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
Doesn't it work like the DIR command? If you don't specify the directory it assumes the last one you accessed* on that drive? * That's not worded clearly, but I hope the concept gets across.
-
The result of Directory.GetFiles("c:") is well defined. You get the same result as if you typed "dir c:" from a command prompt. The result is the contents of the current directory on the c drive. The result of Directory.GetFiles(@"c:\") is the contents of the root directory. If you leave off the '\', Directory.GetFiles() will return a relative path to the current directory on the specified drive. So, Directory.GetFiles(@"c:\blah") is the contents of the blah directory off of the root and Directory.GetFiles(@"c:blah") is the contents of the blah directory off of the current directory on the c drive. If you leave off the drive, Directory.GetFiles() will return either an absolute or relative path on the current drive. So, Directory.GetFiles(@"\blah") is the contents of the blah directory on the current drive and Directory.GetFiles(@"blah") is the contents of the blah directory off of the current directory of the current drive.
ahh. I was using the overload with a filter and assuming the default directory is the one where the executable was located nothing would be returned. Obscure legacy support. *sigh*
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
ahh. I was using the overload with a filter and assuming the default directory is the one where the executable was located nothing would be returned. Obscure legacy support. *sigh*
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
dan neely wrote:
assuming the default directory is the one where the executable was located
The default directory is not necessarily where the executable was located. If you run it through a shortcut, it's the "Start in:" directory. If you run it from CMD, it's the current directory when the application was called. If it is being run from another process, it's the default folder of that process.
-
ahh. I was using the overload with a filter and assuming the default directory is the one where the executable was located nothing would be returned. Obscure legacy support. *sigh*
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
dan neely wrote:
Obscure legacy support
Hey, the league of old fart keyboard jockeys would liek to have a talk with you! (I relying on this feature very often on the console)
-
dan neely wrote:
NotADirectorException
CEO centric-code? ;P
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008):laugh:
think fast, be brave and dont stop.