Improve exception handling in ModelParser, bump version to 0.2.16

[afihman-tk]

No description provided.

[SEilers]

There are two issues with your pull request:

1. The ModelParser is not the first place to throw an exception if the file does not exist. It is in the Report in the Method
   public static List ParseData(string filename, IProgress progress = null, bool debugAttributes = false) where T : ModelBase, IUfedModelParser, new()

Right now I am not catching the FileNotFoundException but I can implement it there.

2. The debugAttributes flag is for listing unknown UFED Models in order to help finding new Models introduced by Cellebrite.
   You are trying to use this flag for throwing an exeption if it occors. I think this is misleading and will lead to confusion when reading the source code.

Alas, you did not comment which exception exactly is occuring during parsing from a network device.

However, I am thankful you brought this issue up and will implement the FileNotFoundException in the ParseData Method of the Report Class.

I hope this is ok for you.

[afihman-tk]

Hi, thank you for your review! I understand changing code that is used in multiple projects is not easy. All I wanted is to make as little changes as possible, but with having error handling.
Do you have an idea how you want it to be?
The error that I receive is plain IOException.

Cheers,
Alex

[SEilers]

Ok, IOExceptions are annoying and can happen while parsing.
I will throw an IOException directly in the ModelParser, as the result is corrupted then anyways,

I assume this has to do with caching of the network filesystem. (I did not know this was an issue until i ran into it myself)

Under Linux you can watch this using strace.

Sometimes it makes a difference if you call a command directly in the directory or use the full path:

strace yourCLICommand /mnt/NAS/Images/yourImage.ufdr

vs

cd /mnt/NAS/Images/
strace yourCLICommand yourImage.ufdr

Although logically it does not seem to make a difference, I have seen in my environment that running into caching issues on a network filesystem can cause a significant delay!

In your Application you can handle this by setting Environment.CurrentDirectory to the folder where the file is:

string folder = Path.GetDirectoryName(filePath);
string filename = Path.GetFileName(filePath);
string oldDir = Environment.CurrentDirectory;

try
{
    Environment.CurrentDirectory = folder;
    // ... do you parsing work on filename
}
finally
{
     Environment.CurrentDirectory = oldDir;
}

I hope this info helps you.

I will implement throwing IOException in the ModelParser Class this weekend. I want to test it thoroughly and then publish a new release this weekend.

Thank you for your input and patience!

[afihman-tk]

I tried to resolve the issue using Claude and Chatgpt, the issue is, for networking filesystem, when I close a file, it takes time for handle to the file to be released. And when I try to open file I've just closed, I can get a handle of a closing file, and it becomes instantly invalid. Suggested solution was to wait 50 ms or so before opening file. And as you can imagine my program is a microservice that lives in a pod, and has no direct access to low-level networking which is in a VM that is managed by k8s.

[afihman-tk]

Hi, any update?

[SEilers]

Hi, yes.

I opened another branch "Exceptions_Refactoring_ModelParser" where current development is taking place.

Removed all "Console.Write" Code and replaced it with logging to the Logger Class or by a throw statement.
I have to decide on several places if to log or throw.

Also went down from ~850 Compiler Warnings to 4 or so.

I have to harmonize the behaviour of the classes for parsing the metadata.

And then finally make a test release of the lib and test it against several hundered containers.