1. 16 Dec, 2015 1 commit
  2. 29 Sep, 2015 1 commit
    • Allison Karlitskaya's avatar
      GLocalFile: return text/plain for empty files · 202a9c34
      Allison Karlitskaya authored
      Previously, GLib returned text/plain for empty files.
      
      This is important because people may want to open empty (eg:
      just-created) text files with the text editor.
      
      An unintended side-effect of b6fc1df0
      caused GLib to start returning application/octet-stream instead of
      text/plain for these files.
      
      This commit is essentially a revert of that commit, with a different
      solution: we move the special-case up a bit in the function and
      hard-code it to text/plain.
      
      This change does not exactly maintain the old behaviour: previously, a
      "fast" lookup would have returned application/octet-stream on an empty
      file and now it will return text/plain.  I consider this to be an
      improvement (since we're returning better data) and don't expect it to
      cause problems.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=755795
      202a9c34
  3. 21 Aug, 2015 2 commits
  4. 05 Jan, 2015 1 commit
  5. 23 Jul, 2014 1 commit
  6. 22 Jun, 2014 1 commit
  7. 11 Mar, 2014 1 commit
  8. 31 Jan, 2014 1 commit
  9. 19 Jan, 2014 1 commit
    • Marc-André Lureau's avatar
      win32: silence build warning · 2873b3c2
      Marc-André Lureau authored
      glocalfileinfo.c: In function '_g_local_file_info_get':
      glocalfileinfo.c:1955:11: warning: passing argument 3 of
      'get_thumbnail_attributes' from incompatible pointer type [enabled by
      default]
                 get_thumbnail_attributes (path, info, &statbuf);
                 ^
      glocalfileinfo.c:1285:1: note: expected 'const struct GStatBuf *' but
      argument is of type 'struct _stati64 *'
       get_thumbnail_attributes (const char     *path,
      
      https://bugzilla.gnome.org/show_bug.cgi?id=711547
      2873b3c2
  10. 17 Jan, 2014 1 commit
    • Marc-André Lureau's avatar
      gio: fix small memory leak on local xattr · d3c729bf
      Marc-André Lureau authored
      g_strconcat() allocates memory, it needs to be freed.
      
      ==10653== 1,400 bytes in 50 blocks are definitely lost in loss record
      1,838 of 1,851
      ==10653==    at 0x4A0645D: malloc (in
      /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==10653==    by 0x54ACB22: g_malloc (gmem.c:102)
      ==10653==    by 0x54ACE4D: g_malloc_n (gmem.c:343)
      ==10653==    by 0x54C8463: g_strconcat (gstrfuncs.c:589)
      ==10653==    by 0x4D6ED38: get_xattrs_from_fd (glocalfileinfo.c:660)
      ==10653==    by 0x4D71622:
      _g_local_file_info_get_from_fd (glocalfileinfo.c:2028)
      ==10653==    by 0x4D731A0:
      g_local_file_input_stream_query_info (glocalfileinputstream.c:356)
      ==10653==    by 0x4C996D8:
      g_file_input_stream_query_info (gfileinputstream.c:148)
      ==10653==    by 0x4C863F6: file_copy_fallback (gfile.c:3120)
      ==10653==    by 0x4C86DD2: g_file_copy (gfile.c:3398)
      
      https://bugzilla.gnome.org/show_bug.cgi?id=722357
      d3c729bf
  11. 20 Nov, 2013 2 commits
    • Dan Winship's avatar
      Replace #ifdef HAVE_UNISTD_H checks with #ifdef G_OS_UNIX · 158dde05
      Dan Winship authored
      In Windows development environments that have it, <unistd.h> is mostly
      just a wrapper around several other native headers (in particular,
      <io.h>, which contains read(), close(), etc, and <process.h>, which
      contains getpid()). But given that some Windows dev environments don't
      have <unistd.h>, everything that uses those functions on Windows
      already needed to include the correct Windows header as well, and so
      there is never any point to including <unistd.h> on Windows.
      
      Also, remove some <unistd.h> includes (and a few others) that were
      unnecessary even on unix.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      158dde05
    • Dan Winship's avatar
      Require POSIX.1 (1990) compliance on unix · 3981cddb
      Dan Winship authored
      Assume unix platforms support the original POSIX.1 standard.
      Specifically, assume that if G_OS_UNIX, then we have chown(),
      getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
      <sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
      
      Additionally, since all versions of Windows that we care about also
      have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
      
      Also remove one include of <sys/times.h>, and the corresponding
      configure check, since the include is not currently needed (and may
      always have just been a typo for <sys/time.h>).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      3981cddb
  12. 23 Oct, 2013 1 commit
    • Allison Karlitskaya's avatar
      file-info: Add a G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID attribute · fe706974
      Allison Karlitskaya authored
      This indicates whether the thumbnail (given by G_FILE_ATTRIBUTE_THUMBNAIL_PATH)
      is valid — i.e. to represent the file in its current state. If
      G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID is FALSE (for a normal _or_ failed
      thumbnail) it means the file has changed since the thumbnail was generated, and
      the thumbnail is out of date.
      
      Part of checking thumbnail validity (by the spec) involves parsing
      headers out of the thumbnail .png so we include some (small) code to do
      that in a separate file.  We will likely want to copy this code to gvfs
      to do the same for GVfsFile.
      
      Heavily based on a patch from Philip Withnall <philip.withnall@collabora.co.uk>
      who suggested the feature and designed the API.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=709898
      fe706974
  13. 16 Apr, 2013 1 commit
  14. 13 Mar, 2013 1 commit
    • Allison Karlitskaya's avatar
      glocalfileinfo: Stop using PATH_MAX for .hidden · 3902006a
      Allison Karlitskaya authored
      We were using PATH_MAX to size a static array for reading lines from
      the .hidden file.  Some platforms (Hurd) don't declare a PATH_MAX.
      
      Switch to using g_file_get_contents() and g_str_split('\n') instead.
      
      Also take the time to clean up a bit with a switch to using a 'set mode'
      GHashTable (since this code was originally written before we had those).
      
      This patch is largely based on a patch from Emilio Pozuelo Monfort (who
      also reported the bug).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=695147
      3902006a
  15. 29 Jan, 2013 1 commit
    • Colin Walters's avatar
      Add g_close(), use it · f398bec5
      Colin Walters authored
      There are two benefits to this:
      
      1) We can centralize any operating system specific knowledge of
         close-vs-EINTR handling.  For example, while on Linux we should never
         retry, if someone cared enough later about HP-UX, they could come by
         and change this one spot.
      2) For places that do care about the return value and want to provide
         the caller with a GError, this function makes it convenient to do so.
      
      Note that gspawn.c had an incorrect EINTR loop-retry around close().
      
      https://bugzilla.gnome.org/show_bug.cgi?id=682819
      f398bec5
  16. 11 Jan, 2013 1 commit
  17. 06 Dec, 2012 2 commits
  18. 28 Nov, 2012 3 commits
  19. 19 Nov, 2012 1 commit
  20. 26 Oct, 2012 1 commit
    • Cosimo Cecchi's avatar
      file-info: catch thumbnail files in large directory as well · d681b581
      Cosimo Cecchi authored
      When building the file attribute table info for local files, use
      thumbnail paths in $XDG_CACHE_DIR/thumbnails/large in addition to
      $XDG_CACHE_DIR/thumbnails/normal.
      
      Failing to do this would cause an application that creates large
      thumbnails by default to never find any value for
      G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no
      G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the
      application to either think thumbnailing is still in progress, or
      blindly requeue thumbnail operations in a loop.
      
      Large thumbnails are generally preferred, so we now default to the path
      of a large thumbnail (in case both are present).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=686895
      d681b581
  21. 19 Sep, 2012 1 commit
    • Chun-wei Fan's avatar
      gio: Fix build on Windows · 3dd65859
      Chun-wei Fan authored
      The newly-introduced functions, g_content_type_get_symbolic_icon() and
      g_content_type_get_generic_icon_name() don't seem to be for Windows, at
      least for now.  So filter them out from gio.symbols on Windows.
      
      Also, glocalfileinfo.c calls g_content_type_get_symbolic_icon() in
      get_icon(), so only build that code when on Unix, for the time being.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=684278
      3dd65859
  22. 30 Aug, 2012 2 commits
  23. 28 Aug, 2012 1 commit
  24. 04 Jul, 2012 1 commit
  25. 13 Jun, 2012 1 commit
  26. 16 Nov, 2011 1 commit
  27. 07 Nov, 2011 1 commit
  28. 08 Sep, 2011 1 commit
  29. 03 May, 2011 1 commit
    • Dan Winship's avatar
      Fix usage of _GNU_SOURCE · e56498ee
      Dan Winship authored
      _GNU_SOURCE must be defined before including any other (system)
      header, so defining it in glib-unix.h (and hoping no one has included
      anything else before that) is wrong. And the "#define _USE_GNU"
      workaround for this problem in gnetworkingprivate.h is even wronger
      (and still prone to failure anyway due to single-include guards).
      
      Fix this by defining _GNU_SOURCE in config.h when building against
      glibc. In theory this is bad because new releases of glibc may include
      symbols that conflict with glib symbols, which could then cause
      compile failures. However, most people only see new releases of glibc
      when they upgrade their distro, at which point they also generally get
      new releases of gcc, which have new warnings/errors to clean up
      anyway.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=649201
      e56498ee
  30. 26 Apr, 2011 1 commit
  31. 03 Nov, 2010 1 commit
  32. 08 Jul, 2010 1 commit
    • Matthias Clasen's avatar
      Handle MLS selinux policy better · 71e7b580
      Matthias Clasen authored
      Following the behaviour of ls here, we should return at least the
      file name, if we can't get any other information about a file. To
      do this, handle EACCESS on stat() calls.
      
      Patch by Tomas Bzatek, see bug 623692
      71e7b580
  33. 07 Jul, 2010 1 commit
  34. 30 Mar, 2010 1 commit
    • Tor Lillqvist's avatar
      Define a public documented type for the struct stat used by g_stat() · 1229281d
      Tor Lillqvist authored
      Define GStatBuf as the type used by g_stat() and g_lstat(). Replaces
      the non-public struct tag _g_stat_struct. Mostly relevant for Windows
      where there are several variants of stat-style structs. On POSIX, is
      just another name for struct stat.
      
      Actually, also on many POSIX systems there are in fact several
      variants of struct stat and corresponding stat() and lstat()
      functions, but as g_stat and g_lstat are normally on POSIX just macros
      that expand to stat and lstat, this should not cause a problem. It's
      only when it's the actual g_stat() or g_lstat() implementation inside
      GLib that gets called that one needs to be sure the passed struct is
      the same as what GLib expects.)
      1229281d