John Darrington <j...@darrington.wattle.id.au> writes:
> On Mon, Feb 06, 2012 at 09:46:40PM -0800, Ben Pfaff wrote:
> Jeremy Lavergne <jer...@lavergne.gotdns.org> writes:
>
> > It sounds like the open dialog is the only place were bugs have
> arisen: what
> > information can I get you to help in that area?
>
> [...]
>
> > ??? Problem with filtering on "Open.." window. Not
> > identifying ".sav" or ".sps" files, though it finds them
> > fine when you request "All Files"
>
> (I've seen a similar report from a Windows user, too.)
>
> John, it looks like before commit 34bfbdd99ac80a8 (Filter file
> choosers by mimetype instead of file name), which was first
> released in 0.7.8, we selected files for the Open dialog on the
> basis of extension. Following that commit, though, we select
> files only on the basis of mime type. Would it be wise to allow
> either kind of criterion for filtering files?
>
> There are a lot of programs (especially games) which save files with a .sav
> extension. See http://filext.com/file-extension/SAV
> SPSS comes quite low in that list. Would you really want to deal with
> bug reports that pspp gives funny error messages when trying to open
> a "http://filext.com/file-extension/SAV"; ?
Well, SPSS is the oldest still-existent user of that extension,
so it gets priority :-)
> The commit doesn't mention a rationale for the change, and I
> don't remember either.
>
> The rationale is that the characters of a filename which follow
> the "." (if any) are not a reliable indicator of the contents of the file.
> Operating systems which conform to the freedesktop standards examine the
> contents of the file, in order to determine the mimetype. Others have
> heuristic methods which produce varying results.
I did some delving into the GTK+ code for this. It eventually
ends up in the following function in GIO:
static char *
get_content_type (const char *basename,
const char *path,
GLocalFileStat *statbuf,
gboolean is_symlink,
gboolean symlink_broken,
GFileQueryInfoFlags flags,
gboolean fast)
{
if (is_symlink &&
(symlink_broken || (flags & G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS)))
return g_strdup ("inode/symlink");
else if (S_ISDIR(statbuf->st_mode))
return g_strdup ("inode/directory");
#ifndef G_OS_WIN32
else if (S_ISCHR(statbuf->st_mode))
return g_strdup ("inode/chardevice");
else if (S_ISBLK(statbuf->st_mode))
return g_strdup ("inode/blockdevice");
else if (S_ISFIFO(statbuf->st_mode))
return g_strdup ("inode/fifo");
#endif
#ifdef S_ISSOCK
else if (S_ISSOCK(statbuf->st_mode))
return g_strdup ("inode/socket");
#endif
else
{
char *content_type;
gboolean result_uncertain;
content_type = g_content_type_guess (basename, NULL, 0,
&result_uncertain);
#ifndef G_OS_WIN32
if (!fast && result_uncertain && path != NULL)
{
guchar sniff_buffer[4096];
gsize sniff_length;
int fd;
sniff_length = _g_unix_content_type_get_sniff_len ();
if (sniff_length > 4096)
sniff_length = 4096;
#ifdef O_NOATIME
fd = open (path, O_RDONLY | O_NOATIME);
if (fd < 0 && errno == EPERM)
#endif
fd = open (path, O_RDONLY);
if (fd != -1)
{
ssize_t res;
res = read (fd, sniff_buffer, sniff_length);
close (fd);
if (res >= 0)
{
g_free (content_type);
content_type = g_content_type_guess (basename,
sniff_buffer, res, NULL);
}
}
}
#endif
return content_type;
}
}
In other words, on Windows only the extension matters.
Elsewhere, the file contents are examined. I think that means
that Jeremy needs to do something to ensure that the signatures
for .sav and .por files are in the xdg mime-type database. It
looks like that database is in /usr/(local/)share/mime/magic by
default. I see entries for x-spss-por and x-spss-sav in that
file on my system. Jeremy, can you arrange to add entries there
for those types on MacPorts?
Now, in fact, I remember that I had to file a similar request to
get these mime-types to show up on GNU/Linux, too:
https://bugs.freedesktop.org/show_bug.cgi?id=20834
Thanks,
Ben.
--
Ben Pfaff
http://benpfaff.org
_______________________________________________
pspp-dev mailing list
pspp-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-dev
