Supported File Types?

This topic contains 21 replies, has 8 voices, and was last updated by  mynameisJR 5 years, 9 months ago.

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
    Posts
  • #4248

    TacoJohn
    Participant

    Which types of files are supported?

    I don’t see the list in the program documentation. Although I do see a list of file types in the resources.

    #4549

    mynameisJR
    Participant

    And there in Preferences you will see the explanation:

    This list contains all file types Disk Drill will work with when scanning your hard drive. Those which are selectable are supported by deep scan.

    Recovery from Vault and Quick Scan are not signature-based. They work with different algorithms, and are capable of recovering all file types.

    #4550

    TacoJohn
    Participant

    Alright. I missed the filetype list in the preferences.

    I’ve seen a few apps which allow one to create their own signature for unknown filetypes. Basically they have you select a handful of files of that unknown type and creates a signature based on those. I assume they use some kind of rolling hash & maybe a simple diff of the first X bytes. If nothing else, you could use the function to create your signatures faster.

    How difficult would this be to implement?

    #4551

    mynameisJR
    Participant

    We definitely have this on our todo list. I don’t think it’s impossible, but I don’t think it’s that effective as well. For example, a BMP image will have only 4 bytes of unique file signature, imagine that it’s so simple to mix it with another file type, when the signature is so small in size. So, speaking of data recovery based on deep scanning (file signatures) it’s the least reliable method anyway. Even if you could build your own signatures based on file types that only you have, they will require a lot of testing before including in the public release. But that’s of course a great feature.

    #4552

    TacoJohn
    Participant

    Full decoding of the file headers are almost always preferable as you could for instance know the likely size of the file and possibly a built-in hash on a few types. The flexibility of on demand signatures is undeniable.

    Assuming a straight equal bits comparison, 1/2^(N-1) of the bits are going to be the same in N random files. Forcing a signature to be 4 bytes in length, it should be 1/32^(N-1). Which I think should give a false positive in creating a signature every 4 MB w/ 5 files as input assuming it’s not aligned at a 4 byte boundary (rolling hash on each bit). My math may be far off btw.

    #4553

    mynameisJR
    Participant

    _MY_ math is far OFF yours 🙂 I’ll let you know what my developers think of it shortly.

    #4554

    TacoJohn
    Participant

    Yeah, 4am doesn’t make for quality thoughts.

    #4566

    JoMaDo
    Participant

    in the Preference List there are only a few file types selectable. This means only those can be recovered by deep scan?!

    For example I need to recover excel sheets. But unfortunately .xls is not supported and also .ppt Powerpoint presentations aren’t.

    A minimum requirement for me is, that disk drill is able to detect documents of the MS Office suite as many users work with these documents. Many work in a crossplatform environment ( i.e. OS X at home Windows at work).
    I Hope you can implement the revovery of these file types for a deepscan.

    I noticed that you implemented the newest filetypes i.e. XLSX, but naturally data to be recovered are quite often a little bit older. So it is no use fo rme at the moment, as the files I try to discover where saved as .xls, .ppt

    #4567

    mynameisJR
    Participant

    More file types will be supported with every new release. We are not able to add ALL files to be supported by Deep Scan right now.

    As we recommend, please, enable Recovery Vault 🙂

    #4570

    mynameisJR
    Participant

    We’ll be adding a lot of file signatures to Disk Drill. The list is actually absolutely unbelievably huge. All specific file types requested by you and many others are prioritized higher in our roadmap now.

    #4569

    hayvan
    Participant

    Any changes .pages docs will be supported in the near future?

    #4574

    TacoJohn
    Participant

    Seems that HFS compression & NTFS compression will destroy the signature that you are looking for. If it’s deterministic in how it compresses the first chunk of the file, it may make a new signature that is recognizable.

    #4575

    mynameisJR
    Participant

    Any compression of the disk, as well as encryption of the disk, will most possibly make it unrecognizable by Disk Drill. Nothing to do here as this means that you are trying to protect yourself from data recovery and then at the same time run it.

    And yes, .pages will be supported soon.

    #4576

    TacoJohn
    Participant

    HFS & NTFS compression are file level compression, as opposed to full disk compression. It would be interesting to attempt decompression at the beginning of every block and then run the signature check.

    But assuming a compressed version of the file has a recognizable signature, it would be faster (cpu time, not programmer time) to make a signature of the compressed file.

    #4577

    mynameisJR
    Participant

    TacoJohn, several points here… we are talking about Deep Scan, right? The recovery method which is based on file signatures…

    Point #1. It’s hardly possible to recover compressed files at all, as their signatures are altered by compression algorithms completely. Moreover, file signature might not be placed in the beginning of a file. When this file is compressed its signature will most probably be compressed/changed as well.
    Point #2. On the other hand, if compression is applied “by-cluster”, and the size of the cluster is a known value, we can find out if the cluster is compressed, and decompress it. Then it’s possible to search for file signatures in a regular way. However, see below.
    Point #3. When searching for files using Deep Scan, Disk Drill has to define not only the file’s signature but also the length of the file. Generally speaking, we’ll need to decompress the whole file, as most file types will also have another signature that identifies the end of the item. Read it: time, alternative storage space, etc.
    Point #4. The majority of files are already compressed, there’s no need to apply additional compression to them (archives, video, audio).
    Point #5. NTFS is not a native Mac OS file system. Transparent compression in HFS+ is not documented well-enough yet. We suspect it’ll be implemented not earlier than Mac OS 10.7.

    To sum it up: currently Disk Drill won’t support data recovery of compressed files. Though it’s theoretically possible to realize, the task has low priority. See points #4, 5.

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic.