1. 12 Sep, 2018 1 commit
    • LRN's avatar
      W32: new GFileInfo attributes · c6b4eff0
      LRN authored
      G_FILE_ATTRIBUTE_DOS_IS_MOUNTPOINT allows mountpoints
      (NTFS reparse points with IO_REPARSE_TAG_MOUNT_POINT tag) to
      be told apart from symlinks (NTFS reparse points with
      IO_REPARSE_TAG_SYMLINK tag), even though both are reported
      by glib as "symlinks".
      
      G_FILE_ATTRIBUTE_DOS_REPARSE_POINT_TAG allows the exact
      reparse tag value to be obtained by the user. This way
      even more exotic reparse points can be identified and
      handled by the user (glib itself currently has no code
      to work with any reparse points that are not symlinks
      or mountpoints).
      c6b4eff0
  2. 29 May, 2017 1 commit
  3. 20 Aug, 2015 1 commit
    • Debarshi Ray's avatar
      fileinfo: Add a G_FILE_ATTRIBUTE_STANDARD_IS_VOLATILE attribute · fa0f51dd
      Debarshi Ray authored
      This is meant for opaque, non-POSIX-like backends to indicate that the
      URI is not persistent. Applications should look at
      G_FILE_ATTRIBUTE_STANDARD_SYMLINK_TARGET for the persistent URI.
      Examples of such backends could be a portal for letting sandboxed
      applications access the file-system, or a database-backed storage like
      Google Drive.
      
      In these cases, the user visible file and folder names are different
      from the real identifiers, used by the backend. So, a request to
      create google-drive://user@gmail.com/foo/New\ File, would actually
      lead to google-drive://user@gmail.com/foo/bar on the server even though
      the user visible name is still "New File". Since the server-defined URI
      is persistent and sanity-checked by the backend, it is recommended that
      applications switch to it as soon as possible. Backends will try to
      keep a mapping from "fake" to "real" URIs, but those are only on a
      best effort basis. They might not be persistent or have the same
      guarantees as the "real" URIs.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741602
      fa0f51dd
  4. 31 Jan, 2014 1 commit
  5. 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
  6. 30 Aug, 2012 1 commit
  7. 08 Mar, 2010 1 commit
  8. 06 Jul, 2009 1 commit
  9. 29 Jun, 2009 3 commits