Strange bug in different compilation mode

Question

I'm encountering a very strange bug which appears only when compiling in Release mode, while in Debug mode the code runs perfectly. Moreover, the bug is encountered only in one machine (a user reported this).

This is the stack trace:

System.IO.FileNotFoundException: Unable to find file 'C:\Users...\FileName.txt'. File name: 'C:\Users...\FileName.txt' in System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) in System.IO.FileInfo.get_Length() in PatcherNET4.FileHandler.LocalFile.get_Size() in PatcherNET4.FileHandler.CachedFile.IsLocalValid(LocalFile file) in PatcherNET4.FileHandler.FileManager.<>c__DisplayClassd.b__9(CachedFile file) in System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 source, Func2 predicate) in PatcherNET4.FileHandler.FileManager.RemoveLocalFiles() in PatcherNET4.FileHandler.FileManager.DownloadMissingFiles() in System.Threading.ThreadHelper.ThreadStart_Context(Object state) in System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) in System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) in System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) in System.Threading.ThreadHelper.ThreadStart()

And this is the code:

// CachedFile
...
public bool IsLocalValid(LocalFile file)
{
    var checkName = file.Name == Name;
    var checkSize = file.Size == Size;
    var checkLastWrite = file.LastWriteTime == LastWriteTime;
    return checkName && checkSize && checkLastWrite;
}
...

//LocalFile
...
public uint Size
{
    get
    {
        _info.Refresh();
        return (uint)_info.Length;
    }
}
...

How is this possible? I can assure you that there is no difference in the interested pieces of code between the release and debug mode. I don't really know what to do, this is probably the strangest bug I've ever seen.

Is the path relative? When you run in debug/release, the running directory for the program will be different. — tnw, Apr 14 '14 at 19:55
Yes, it exists; moreover, the bug happened with two different files in two different runs — Niccolò Campolungo, Apr 14 '14 at 19:55
An error that depends only of the compiling mode smells like a running condition. — SJuan76, Apr 14 '14 at 19:55
@tnw: yes, it is relative (thanks for this point, I'll try that tomorrow). But how is it possible that this bug is encountered only in one machine, while 200 and more people are using it? SJuan, for example? — Niccolò Campolungo, Apr 14 '14 at 19:59
I'd also like to understand why there are downvotes. Am I providing few informations? This is a strange case, I don't really know what to give you — Niccolò Campolungo, Apr 14 '14 at 20:02
"System.IO.FileNotFoundException: Unable to find file 'C:\Users...\FileName.txt'." *is* the error - that is, the file can't be found (which likely means the path is different/incorrect between good and bad running *environments*). Follow it back from there. Don't blame the compiler. — user2864740, Apr 14 '14 at 20:04
@user2864740, I tried. It has no sense (to me), the file is there. — Niccolò Campolungo, Apr 14 '14 at 20:05
@LightStyle have u tried to remove (manually) all files from debug/release directories and ReBuild all projects? — Only a Curious Mind, Apr 14 '14 at 20:10
@HackerMan what do you mean by "using"? Lucas, yes, I tried everything I had in my head. Nothing worked. Only giving the user the program compiled in debug mode. — Niccolò Campolungo, Apr 14 '14 at 20:13
No, it is not open while the program is running, but it's there — Niccolò Campolungo, Apr 14 '14 at 20:20

score 0 · Answer 1 · answered Apr 14 '14 at 20:12

0

put FileName.txt in the Unable to find file 'C:\Users...\(here) directory

answered Apr 14 '14 at 20:12

HackerMan

904
7
11

@LightStyle check the file name brother System.IO.FileNotFoundException <----look carefully! – HackerMan Apr 14 '14 at 20:14
Already did. I'm not that stupid, don't worry. The file is there, and the program is not recognizing it. I also thought it could be a problem of the path (it contained a space inside of it), I made the user change it and it didn't work either. – Niccolò Campolungo Apr 14 '14 at 20:15
Well, it's possible. But how do you explain that this "stupid program" works on 200+ machines without errors and it doesn't work **only in release mode** on a single machine? – Niccolò Campolungo Apr 14 '14 at 20:17
It's possible. But I can't yet explain myself how it is possibly different the same program in Debug and Release mode. – Niccolò Campolungo Apr 14 '14 at 20:21
@LightStyle if you use **current directory** in debug mode...you should use **absolute** location in release mode....ok – HackerMan Apr 14 '14 at 20:25

score 0 · Answer 2 · answered Sep 02 '14 at 01:01

The first thing I'd try is to verify the file exists at runtime and go from there.

if (!File.Exists(fileName))
{
    // do something
}

If the file doesn't exist (I believe you when you say it's missing) then consider the alternatives. Has the file been deleted already? I notice in the stacktrace there's RemoveLocalFiles, so perhaps it's already been run. Maybe a user pressed a button twice? race condition. Separate thread? User is logged in on two machines and has roaming profiles. Or something like that.

Regardless of whether it's a bug or not, it's better to be defensive and include a check to make sure the file exists (or catch the exception if that's your preference).

Strange bug in different compilation mode

2 Answers2