[Top][All Lists]

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

Re: Fwd: PSPP Testing

From: Ben Pfaff
Subject: Re: Fwd: PSPP Testing
Date: Wed, 08 Feb 2012 22:28:42 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

John Darrington <address@hidden> writes:

> On Mon, Feb 06, 2012 at 09:46:40PM -0800, Ben Pfaff wrote:
>      Jeremy Lavergne <address@hidden> 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
> 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 ""; ?

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");
    #ifdef S_ISSOCK
      else if (S_ISSOCK(statbuf->st_mode))
        return g_strdup ("inode/socket");
          char *content_type;
          gboolean result_uncertain;

          content_type = g_content_type_guess (basename, NULL, 0, 

    #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)
                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);

          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:


Ben Pfaff

reply via email to

[Prev in Thread] Current Thread [Next in Thread]