0

Overview:

I have an issue where 1 out of a hundred PCs just started having an issue with the LibTiff library not wanting to open ANY of my tiff images. I suspect it has to do with a dependency file that has changed. I have seen this issue before but can not remember how I solved the issue (I think I replaced some dll files with ones from another PC that was working). I tried to use Dependency Walker to determine what files were used by the LibTiff.Net dll but could not get Dependency Walker to work, it just had errors opening a bunch of dlls.

Question:

Is it possible to know WHY a file is not being opened successfully? All the method does is return NULL, is there a way to get an error of some type? I know there are no locks on the files (did a reboot, and checked other ways). I know the tiff files are good with no issues (copied them to another PC that uses the same software and it reads it just fine). Could I use something like "GetLastError" to return a reason the Open method is returning Null?

Here is my current usage:

using BitMiracle.LibTiff.Classic;

using (Tiff tImage = Tiff.Open(sFileName, "r"))
{
    if (tImage == null)
    {
      //File could not be opened
      lastError = "File could not be opened.";
      return null;
    }
}
Arvo Bowen
  • 4,524
  • 6
  • 51
  • 109

1 Answers1

0

Moved to be an answer from my comment:

It is possible to determine, however you would need to do the checks individually since Tiff.Open does not throw an exception. It either opens the file or returns null.

I would add a if(!File.Exists(sFileName)) throw new FileNotFoundException("File was not found.", sFileName);. That would be an important one as this could occur if the file is stored on a network drive and that drive becomes temporarily unavailable.

See also this question/answer for checking if a file is locked. That would be another big reason why it may not be able to open the file. If the image file is opened by your code or another application and the resource is not released it will remain locked. Here is the code from the linked discussion:

protected virtual bool IsFileLocked(FileInfo file)
{
    FileStream stream = null;

    try
    {
        stream = file.Open(FileMode.Open, FileAccess.Read, FileShare.None);
    }
    catch (IOException)
    {
        //the file is unavailable because it is:
        //still being written to
        //or being processed by another thread
        //or does not exist (has already been processed)
        return true;
    }
    finally
    {
        if (stream != null)
            stream.Close();
    }

    //file is not locked
    return false;
}

In general, you should probably perform your own checks before attempting to open it; or you can just try to open it and check if it returns null, then you can do your checks then. It's really up to you since it doesn't throw its own exceptions.

Community
  • 1
  • 1
gmiley
  • 6,531
  • 1
  • 13
  • 25
  • I actually do a BUNCH of my own checks for other reasons. That's the crazy thing though... I see NO reason why it should not open the tiff! It DOES exist, it is 100% a good tiff, it's NOT locked in any way, and both the application (with the TibTiff.Net dll) and the tiff image put on another machine seem to have no problems at all. :/ – Arvo Bowen Jan 26 '16 at 13:32
  • Do all of the machines run the same version of windows and have the same version of .Net framework installed? Are they also the same hardware (32 vs 64)? – gmiley Jan 26 '16 at 13:34
  • Yes on all accounts. They are all 64bit machines all running Windows 7, and all have Dot Net Framework 4 (Client and Extended) installed. These are all imaged stations so they are identical. I could re-image the station but that is a huge pain because it's remote. I would much rather find out what files have changed. I tried uninstalling the framework, rebooting, and then reinstalling it. That yielded the same results. I also tried reinstalling my application. – Arvo Bowen Jan 26 '16 at 13:53
  • @ArvoBowen I would seriously doubt that you're suddenly missing a library. If it is library related, the only real way you could have a problem, without your application completely blowing up, would be a version mismatch. Check the properties of the reference. Is `Specific Version` set to `True` or `False`? Can you attache the debugger to the process on the machine that is failing? If not, I would add checks using the `File` class before calling `Tiff.Open` and throw exceptions. Also, is it possible that the format of the file changed? Are you performing any other operations on those files? – gmiley Jan 26 '16 at 18:54
  • I never said anything about a "missing" library. The LibTiff.Net library that I have referenced in the project and that my program uses is in the same directory as my program and is the same (correct) file. What I was saying was I think some files that the library depends on have changed. Maybe some APIs no longer exist or something that the library is trying to use? Spec Ver is set to False, and as i have said a few times... I KNOW the file is a good tiff image, and that it exists and has no lock on it. I have no clue what other checks i could be doing on the file. – Arvo Bowen Jan 26 '16 at 19:34
  • Also, you say that you "know there are no locks... reboot and checked other ways", but you should have these checks in your code before attempting to open the file, or to check for the problem if it returns null. It may be that your application is actually locking the file and it isn't being unlocked and dereferenced properly afterwords. You can't say that you know it isn't locked, that it exists, etc. That means next to nothing. The checks need to be done in your application at the point that your code attempts to access it. – gmiley Jan 26 '16 at 19:36
  • Ok so trying to switch tracks because this is going in the wrong direction... Up until three days ago everything on this system was working perfectly. Nothing on my end changed at all, it all just stopped working after being in production for years. I just noticed when looking online that LibTiff is somehow included in Adobe Acrobat! As soon as the issue started up (a few days back) the ONLY update had been an Adobe Acrobat update! Maybe that had something to do with it? – Arvo Bowen Jan 26 '16 at 20:23