Re: Suggestion for file type detection approach

[Arvind Narayanan <arvindn meenakshi cs iitm ernet in>]

My 2 cents:

* It is fairly common to get misnamed files. For instance, a webserver
has a cgi script that generates a pdf file on the fly and the browser
prompts the user to save it as .cgi. I have seen users become totally
confused by this. Had they been using nautilus they would have opened
the file without any problem.

* I'm not sure if it is "natural" for users to associate file type with
file extension. Even if it is, its just not feasible on Unix. On 
MS-windows it is Ok because the OS has an idea about file types, but
on Unix it would definitely be an ugly hack.

* The speed depends greatly on the type of files. If they are mostly
folders, it is very fast but if they are executables or mp3s it is very
slow. The result is that performance is acceptable most of the time
but is very bad some of the time.

* Nothing is displayed before file type is completely determined for all
the files in the directory. IMHO changing this would greatly alleviate
the speed problem. Do file type detection only for files in the current
view.

* Caching would also lead to a big speed boost. At a minimum, sniffed
types for files in the current navigation stack should be cached, so
that back and forward are instantaneous.

* Another suggestion for speed: Use file type as a "clue" for sniffing.
What I mean is:
	# If the file ends in .tar:
		- First check if it has a tar header. If yes declare it as a tar file
		- If no then do a full sniffing to check for each of the other types
	# If the file is in /somepath/bin/
		- First check if it is an ELF executable. 
		- If not do a full check
	# etc.
This would make sniffing instantaneous for *most* files.

Cheers,
Arvind
-- 
Its all GNU to me