Re: Why file content sniffing sucks



On Wed, 2003-12-24 at 08:07, Fabio Gomes wrote:
> It finally happened. Today I was creating a project. I was using
> Nautilus to create the folders. I created a 'doc' folder where I started
> to write some text files explaining the project. It is a simple backup
> script. One of the text files I wrote was an example of a backup job
> descriptor. The file name was example.txt. The first line of the file
> had a <heade> rtag. After I closed vim, Nautilus ASSUMED that it was an
> HTML file, so it PREVENTED me from opening the f %(#$*%ing file from the
> "incredibly high-quality GNOME UI". The only options were Mozilla and
> OpenOffice. This prevented me from working for several minutes while I
> tried to figure out how to open that damn file without going to the
> console.
> 
> No way. I finally quit. I decided to open a xterm. Not to edit my file
> and make it look less like HTML, but to GET RID of the most stupid
> feature ever implemented in a file manager. I moved
> /etc/gnome-vfs-mime-magic to somewhere else and restarted Nautilus.
> 
> Now the damn file manager sees that the .txt file is really a text file
> (what a great guess! :-)) and allows me to open vim to edit it. Great.
> 
> The only drawback I noticed is that Nautilus does not know how to handle
> .desktop files anymore, even though it recognizes the file type as I can
> see in the properties dialog. Weird.
> 
> Well. This happened to me, an experienced GNOME user. But now stop and
> imagine this kind of thing happening in a company with 100+ machines
> runinng GNOME while dozens of people work with Nautilus to create some
> project... 
> 
> I am thinking seriously about stopping some personal projects in favor
> of creating a patch for nautilus+gnome-vfs to completely disable the
> unrequested opening of files and distribute it among GNOME users. This
> seems to be the only way to convince Nautilus and gnome-vfs maintainers
> to (at least give an option to) disable this thing and make nautilus
> finally work properly and with decent performance.
> 
> File type determination by content is crap. It's a misfeature. It is 
> completely unnecessary. Its benefits do not compensate its drawbacks:
> 
> - The information generated by it is proven to not be accurate enough to
>   be used by a program do determine its actions (the above example and
>   the dozens of related bugs in bugzilla are sufficient). This data
>   should be used merely for informational purposes to the user in the
>   Properties dialog, for example.
> 
> - It reduces performance of Nautilus to a dead turtle:
> 
>   - In addition of simply opendir/readdir/closedir ONCE, 
>     nautilus+vfs does open/read/close on EVERY
>     file in a directory.
> 
>   - A directory with 250 files (1MB each) is sufficient to
>     make nautilus spend 20 seconds on a Duron 950MHz with
>     a 40GB ATA133 hard disk and 256 MB of memory.
> 
>   - The same directory takes less than 50 miliseconds to
>     be loaded in Windows Explorer and xfe[1] (also same
>     machine)
> 
>   - Nautilus spends 40x more time to load the directory
>     than Windows Explorer and xfe[1]
> 
>   - This is obviously the main performance bottleneck of
>     Nautilus.
> 
> - The item above implies on unnecessary evil disk activity
>   (seeking, etc) that reduces the life time of the hardware.
> 
> - The bugs generated by this feature are endless. If you search
>   bugzilla.gnome.org for gnome-vfs bugs related to mime-type mapping,
>   you will see historic examples of:
>   - .mp3 seen as .zip
>   - .1st, .sys, .swf, .ogg, and .ico seen as MP3
>   - .java and .css seen as C/C++
>   - .php and .xml seen as HTML
>   - There are DOZENS of bugs like these.
>   - There will never be a definitive fix for this kind of bug.
> 	
> GNOME needs to cut its own body to get rid of these stupid useless
> unneeded features that only mess with people's work instead of helping
> them.
> 
> The maintainers argue that it is a useful/needed/killer/great feature,
> but Nautilus was never released without it to allow people (even
> themselves) decide if the feature is useful/needed or not.
> 
> If type determination by content was good, we would see it in lots of
> file managers in the world, since it is so trivial to implement. But no.
> The only file manager that implement such a feature is
> Nautilus+GnomeVFS.
> 
> The type determination by content should be available in a context
> menu/menu item such as "Discover file type" that, when the user clicks
> on it, it discovers the type of the file and asks the user if he/she
> wants to fix the file extension/suffix to match the discovered file
> type.
> 
> And you? Do you USER have an opinion about this subject?

Thank you. I've been having similar problems with Nautilus but I thought
it was something I was doing wrong. I've spent hours searching help
files and how-tos trying to discover *what* I was doing wrong. I even
posted a couple of questions to this list. (I never got an answer.) It's
good to know that what I thought was my problem is actually a bug. My
opinion? Yes, the bug should be fixed. Quickly.

Don Henson





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