Using custom file type with same extension but with different magic bytes throws InvalidOperationException on FileTypeValidator.GetFileType()

[jim-craane]

I added a custom file type for mp3 with different magic bytes '0xFF, 0xE3' then the already existing mp3 file type. When I try to get the file type via FileTypeValidator.GetFileType() for this custom file type, I get the following exception:

System.InvalidOperationException: Sequence contains more than one matching element
   at System.Linq.ThrowHelper.ThrowMoreThanOneMatchException()
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at FileTypeChecker.FileTypeValidator.GetFileType(Stream fileContent)

Its failing on line 74 of FileTypeValidator.cs

Suggestion:
Support custom file types with same extensions, but with different magic bytes.

[AJMitev]

@jim-craane The problem is self defined into the error message. There are two file types that match the particular stream content. This is not wanted behavior. Please be sure that your custom class does not contains the bytes array from library mp3 filetype.

[jim-craane]

It does not contain the bytes from the already existing mp3 filetype:

[AJMitev]

There is something wrong here. I am already implemented this file extension into my project and using the sample you provided into issue #9 all current and new tests are passed. Cant reproduce this behavior. New version including this file type and some others will be released today.

[jim-craane]

Yeah you are right, I was implementing my workaround for issue #9, and with that my issue is resolved. Many thanks for the speed.

But I can imagine that it can happen for any other filetype with different magic bytes you didn't implement and someone tries to create a custom implementation for it to get it done. So that's what's this bug is about. It's not only about the mp3 filetype, but for any other file type that misses magic bytes that are also valid for that extension.

[AJMitev]

I don't think your implementation is workaround. Its an absolute valid scenario where the filetype you want to identify is not implemented by design. I think of it as a feature. The purpouse of IFileType and FileType abstraction is to provide that feature.

There is many types that I am not implemented because there are rare to met.

The main goal of this library is to allow programmer to easily adding new types if its nessecery. I am trying to do my best when somebody require an specific type - to be implemented.

[jim-craane]

Ah ok! Then you are right!