4

I'm being completely confused here folks,

My code throws an exception because File.Exists() returns false

public override sealed TCargo ReadFile(string fileName)
{
    if (!File.Exists(fileName))
    {
        throw new ArgumentException("Provided file name does not exist", "fileName");
    }

Visual studio breaks at the throw statement, and I immediately check the value of File.Exists(fileName) in the immediate window. It returns true. When I drag the breakpoint back up to the if statement and execute it again, it throws again.

fileName is an absolute path to a file. I'm not creating the file, nor writing to it (it's there all along). If I paste the path into the open dialog in Notepad, it reads the file without problems.

The code is executing in a background worker. It's the only complicating factor I can think of. I am positive the file has not been opened already, either in the worker thread or elsewhere.

What's going on here?

Rob
  • 26,989
  • 16
  • 82
  • 98
Tor Haugen
  • 19,509
  • 9
  • 45
  • 63
  • Is just the `File.Exists(fileName)` part returning true or the entire `!File.Exists(fileName)` statement returning true? – animuson Mar 07 '10 at 19:20
  • And if you run it without the background worker process - assuming it's not related to the file as you said, how does it behave? – John K Mar 07 '10 at 19:21
  • @SLaks: The path is "C:\Users\tor.CORP\My Development\FatigueTest\Hotspots\AKS_31_2_L11_WellHead_HS1.hcs" – Tor Haugen Mar 07 '10 at 19:27
  • 1
    @animuson: File.Exists(fileName) returns false. The negation returns true. Runtime, that is. Hence the throw. In the immediate window, File.Exists(fileName) returns true. That is, it should never throw. – Tor Haugen Mar 07 '10 at 19:29
  • @jdk: I haven't tried that. It would take some work... – Tor Haugen Mar 07 '10 at 19:30
  • What's the path the file? And what OS do you run on? –  Mar 07 '10 at 19:30
  • What about putting the above method in a new class in a new project and run it directly both in debug and release modes. As a relatively quick test. – John K Mar 07 '10 at 19:36
  • @jdv I'm jdk. You scared me because I didn't remember posting that. Only realized on second glance. Not going crazy ... yet. – John K Mar 07 '10 at 19:43
  • Does it always happen or only sometimes? That is, if repeated 5 times, does this problem happen 5 times? I am asking because I am currently experiencing something similar, but Exists() in *most* cases returns true, but not in all cases (there seems to be some random element to it). – Peter Mortensen May 18 '15 at 21:27
  • cont': Similar to *[Directory.Exists sensible to time?](http://stackoverflow.com/questions/27693569)*: "But every once in a while Directory.Exists(myPath) returned false" – Peter Mortensen May 18 '15 at 21:43

8 Answers8

13

I don't know what's going on, but why do you need the File.Exists test at all? What you're really interested in is, "Can I read this file?" Plenty of other things other than File Not Found can go wrong.

Not to mention, doing a File.Exists test is a race condition because the file could go away after you've done the test, but before you open the file. Just open the file, that's the best test you can do to determine whether you can read the file.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • 3
    +1, that's the only correct way to do this. File.Exists is there primarily for situations like locking files, where you need only to monitor for another process to create or delete the file and never actually intend to open it. – Joel Coehoorn Mar 07 '10 at 19:25
  • 7
    I disagree with this statement. It is prudent to check the file's existence *and also* catch exceptions caused by trying to open a non-existing file. The exceptions could be potentially costly as compared with the additional check and it keeps the code looking cleaner. – Josh Mar 07 '10 at 19:50
  • 2
    Well, even though File.Exists() continues to return false, the code further down actually reads the file successfully. So I guess I'll give you the points here. Still pretty mysterious, though. – Tor Haugen Mar 07 '10 at 19:51
  • I saw Josh's comment just now, and I tend to agree with him. Still, my code runs. For now. – Tor Haugen Mar 07 '10 at 19:52
  • Of course in the OP's example the exception is not avoided at all but the code could certainly be refactored to avoid it. – Josh Mar 07 '10 at 19:53
  • 1
    @Josh Doing the Exists test will especially bite you when you're over a network filesystem, it's unnecessary and technically incorrect. The cost of an exception is negligible as soon as you're comparing it to hitting the disk for anything. – Ana Betts Mar 08 '10 at 00:59
6

File.Exists returns false if you do not have permission to access the folder or file referenced. It may be that you can see the file in the immediates window as an administrator, but when running in a different context you do not have permission.

Julian Martin
  • 194
  • 1
  • 4
  • My guess too. VS is probably running as admin which may explain why the file is visible from the debugger. –  Mar 07 '10 at 19:34
  • True but if you Run (without debug) from an elevated Visual Studio, the child process would also be elevated. – Josh Mar 07 '10 at 19:47
1

Try adding ".ToString()" to the path. For example:

if (!File.Exists(fileName.ToString()))
{
    throw new ArgumentException("Provided file name does not exist", "fileName");
}

Or if joining strings, place it in brackets, then ".ToString":

if (!File.Exists((filePath + "SomeRandomName").ToString()))
{
    throw new ArgumentException("Provided file name does not exist", "fileName");
}

(from question)

I don't quiet understand why ".ToString()" needs to be placed there, but it seems to help...

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
RogueBudz
  • 105
  • 1
  • 8
  • 1
    I take it back, it did seem to help... but it was a false hope – RogueBudz Aug 28 '12 at 13:45
  • It did Work for me! on Debug it returns true, while on Release it returns False I tried adding filname.toString(), it worked like charm! whats the point! – AbeerAhdab Oct 06 '17 at 09:40
1

Try to write it in this way:

if (!Server.Map(fileName)) 
Omar
  • 16,329
  • 10
  • 48
  • 66
1

Well, what is the path of your filename? Remember when you build debug and release you compile to different folders. So if you put the file in the debug folder you won't find it when doing a release build.

Makach
  • 7,435
  • 6
  • 28
  • 37
  • 1
    The path is not related to the build. It actually comes out of a call to Directory.GetFiles(), and so definitely should exist. – Tor Haugen Mar 07 '10 at 19:32
1

I have faced this problem too. The problem is that you are binding the path directly in function file.exist("complete path manually"). Instead of this you should write server.mappath("yourfolder name where file resides") and then concatenate this with your image.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
rajat
  • 11
  • 1
0

Hmm, what sort of things are you doing after this check? Make sure you're cleaning up the file state before dragging your breakpoint again.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
JDPeckham
  • 2,414
  • 2
  • 23
  • 26
0

I had the same problem and found that changing both Debug and Release configurations from AnyCPU to x64 fixed it.

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
Jack
  • 11
  • 1