Re: Suggestion for file type detection approach

Xavier Bestel <xavier bestel free fr> writes:

> > er, good point. no reason you couldn't have an inode->mime_type mappings
> > file somewhere in the directory tho... that should be extremely fast.
> Sure, but then you need a good strategy when updating this file (e.g. if
> you add/remove a file in the directory). This starts to look a bit like
> an embedded database.

The mappings file could be a map from filename->mime-type. Then
adding/removing wouldn't be a problem, but changing a file would be.
The problem is that you need a correct answer to the question "did
this file change since last time?". And there is no way to get that
without reading the file, as far as I know.

The canonical counter-example: someone turns every byte of a file into
'X' and resets the modification dates back to the original. Wihtout
looking inside the file can you tell someone touched it?

Maybe an approximation based on modification dates would be
acceptable, given that sniffing itself is also just an approximation
(Flames about filing bugs notwithstanding). As soon as nautilus
actually _acts_ on the mime type instead of just displaying it, it
could run the sniffer to minimize the damage done from having bad
information in the cache. I don't know what would happen UI-wise when
a mismatch was discovered, though.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]