Confirming.

For local files, we use _gnome_vfs_get_mime_type_internal with a stat buffer and fall back to "text/plain" if no extension and contents information is available.

For remote files, we use gnome_vfs_mime_type_from_name_or_default, which is
a) bogus
b) is passed an "application/octet-stream" fallback MIME type instead of "text/plain"

Milestoning, raising priority,.since it renders Nautilus useless in many situations.

Created attachment 56869 [details] [review]
Proposed patch

Makes all the non-file methods use gnome_vfs_mime_type_from_name and pass "text/plain" as fallback MIME type.

Also fix gnome_vfs_mime_type_from_name_or_default to not blindly return an "application/octet-stream" when xdg_mime_get_mime_type_from_file_name failed.

-	if (mime_type)
+	if (mime_type && mime_type != GNOME_VFS_MIME_TYPE_UNKNOWN)
 		return mime_type;

This will never matter, xdg_mime_get_mime_type_from_file_name will never return a pointer that points to GNOME_VFS_MIME_TYPE_UNKNOWN, in fact GNOME_VFS_MIME_TYPE_UNKNOWN isn't even a variable so it has not only one address.
XDG_MIME_TYPE_UNKNOWN would work though.

Also, I'm not sure treating all remote unknown type files as textfiles instead of unknown is better than treating all such files (wrongly) as text/plain. You say we do this for file://, but that is not true, only if we can sniff it as "looking like text". Try creating a binary file with no extension and see.

I'm not sure what sort of files seb128 meant though. Only text files with no extension? *.txt etc should work, right?

I also totally don't like the patch. I guess we could sniff on smb (is there a method on smb to get a better, i.e. smarter guess of the mime type?)

I just found that in the SFTP spec there is a attributes field which could hint us:

SSH_FILEXFER_ATTR_KNOWN_TEXT        0x00
       SSH_FILEXFER_ATTR_GUESSED_TEXT      0x01
       SSH_FILEXFER_ATTR_KNOWN_BINARY      0x02
       SSH_FILEXFER_ATTR_GUESSED_BINARY    0x03

I am going to take a look at that later ... 

alexander: yes, text files with no extension.
gicmo: any news on this?

okay, this really is not a gnome blocker by definition. it's a major usability issue, but not important enough that it could block a release.

gicmo: Don't count on these attributes! I don't know of any software implementing them.

I think it's really time for some proper MIME type testcases to track the precise changes and their consequences.

I'm setting the bug status to "rejected" as it is really not appropriate.

Maybe we should consider applying the local strategy (i.e. contents sniffing) upon selection.

Unmilestoning, lowering priority.

gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome.

If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs.

@Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together.


General further information: http://en.wikipedia.org/wiki/GVFS 
Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html