Include the filename for the file in question in many of the
error messages in glocalfile.c. This is useful information when
diagnosing such errors, so make it easily available.
http://bugzilla.gnome.org/show_bug.cgi?id=754012
Add filesystem attribute to detect remote filesystems in order to
replace hardcoded filesystem types in GtkFileSystem. Set this attribute
also for GLocalFile appropriately.
Bump version to 2.49.3, so that early adopters of new API have a version
number to target.
This was confusing some static analysis. Through canonicalize_filename()
at construction time, we guaranteed that ->filename is canonical and
absolute, so g_path_skip_root() should never fail.
https://bugzilla.gnome.org/show_bug.cgi?id=731988
Commit 8ece2de964 transplanted a block of
code that contained an early-exit-on-error case which freed several
variables.
Because of the move, the normal-path unconditional free of one of these
variables is now above this early exit case, so if this block is hit, it
will now be a double-free.
Remove that.
https://bugzilla.gnome.org/show_bug.cgi?id=757693
Recent changes to file monitors removed the delay before events were
reported. Among other things, this caused the trash backend of gvfs to
notice trashed files sooner than before.
On noticing trashed files, the backend tries to read the info file to
discover (among other things) the original location of the file.
Unfortunately, g_local_file_trash() does a strange dance when trashing a
file. It does a loop of open(O_EXCL) in order to file an empty filename
in the trash to write an info file to, trashes the file, and only then
writes the contents of the info file. This means that at the time the
file is moved to the trash, the info file is an empty stub.
Change the order so that we write out the actual content of the info
file first. If the actual trash files then we will unlink the info file
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=749314
_wstat32i64() doesn't exist in msvcrt.dll. This doesn't cause a problem
on 32-bit Windows because mingw-w64 #defines _wstat32i64 to _wstati64,
but on 64-bit Windows we get a link error.
In addition, _wstat32i64() takes a struct _stat32i64 *, but
GLocalFileStat is #defined to struct _stati64, which is not the same
type on 64-bit Windows.
Fix by using _wstati64().
https://bugzilla.gnome.org/show_bug.cgi?id=749161
Remove all event merging and dispatch logic from GFileMonitor. The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.
Get rid of GLocalDirectoryMonitor. We will use a single class,
GLocalFileMonitor, for both directory and file monitoring. This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).
Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism. Put it in GLocalFileMonitor. All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.
Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor. All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.
Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor. gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.
Expose g_local_file_is_remote() internally for NFS detection.
With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c
Port the inotify backend to adjust to the changes above. None of the
other backends are ported yet. Those will come in future commits.
Add a new internal constructor for GLocalFile (which itself is private).
This new constructor allows creating a GLocalFile from a dirname and a
basename, assuming that the dirname is already in canonical form and the
basename is a regular basename.
This will be used for creating GLocalFile instances from the file
monitoring code (for signal emissions).
glocalfile.c: In function 'g_local_file_measure_size_of_file':
glocalfile.c:2654:3: warning: passing argument 2 of 'g_lstat' from
incompatible pointer type [enabled by default]
if (g_lstat (name->data, &buf) != 0)
^
In file included from glocalfile.c:68:0:
../glib/gstdio.h:135:5: note: expected 'struct GStatBuf *' but argument
is of type 'struct _stati64 *'
https://bugzilla.gnome.org/show_bug.cgi?id=711547
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
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
Add a convenient and race-free method of watching local files from the
GLib worker thread.
Without this, the race-free way to create a monitor that dispatches
events to the worker thread looked something like this:
- dispatch an idle to the worker thread
- from the idle, create the monitor and connect signals
- from the original thread, wait (on a cond?) until the worker thread
has finished setting up the monitor
- read the file that you were monitoring
which is just ridiculously complicated...
To use the new API:
monitor = g_local_file_monitor_new_in_worker ("/path/to/some/file",
G_FILE_MONITOR_NONE,
&error);
g_assert_no_error (error);
g_signal_connect (monitor, "changed", G_CALLBACK (callback), NULL);
g_local_file_monitor_start (monitor);
'callback' will run from the GLib worker thread.
This is the reason that the start() call was introduced in the previous
commit. The backends that don't use the start() call will have a very
thin race between creating the monitor and connecting the signal, but
hopefully they will be fixed soon.
These new APIs will be used (at least) from gdesktopappinfo to watch for
changes in the desktop file directories.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
It turns out that although dirent is available on mingw32 (where the
code was originally tested), it is not usable from MSVC.
Avoid portability problems by just using GDir.
Also, be careful about ensuring that we utf8-format filenames in our
error messages, and leave out the "file://" component since the strings
we're displaying are not URIs (and we don't want to make them URIs since
the extra escaping would reduce legibility).
Thanks to Chun-wei Fan <fanchunwei@src.gnome.org> for portions of this
patch and for reviews.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
Previously, g_file_copy() would (on Unix) create files with the
default mode of 644. For applications which might at user request
copy arbitrary private files such as ~/.ssh or /etc/shadow, a
world-readable copy would be temporarily exposed.
This patch is suboptimal in that it *only* fixes g_file_copy()
for the case where both source and destination are instances of
GLocalFile on Unix.
The reason for this is that the public GFile APIs for creating files
allow very limited control over the access permissions for the created
file; one can either say a file is "private" or not. Fixing
this by adding e.g. g_file_create_with_attributes() would make sense,
except this would entail 8 new API calls for all the variants of
_create(), _create_async(), _replace(), _replace_async(),
_create_readwrite(), _create_readwrite_async(), _replace_readwrite(),
_replace_readwrite_async(). That can be done as a separate patch
later.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
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
Add a pair of new extension points: 'gio-nfs-file-monitor' and
'gio-nfs-directory-monitor'.
Add a check to GLocalFile when creating a file monitor. If the
requested file is in the user's home directory and the user has an NFS
home directory then attempt to use an implementation of one of the new
extension points. If we don't have any implementations then fall back
to the normal "local" monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
GLocalFile was (in certain situations) translating a path like
"/foo/bar/baz" to "/foo\bar\baz" on win32. Fix it to make sure the
initial directory separator gets canonicalized too.
Fixes gio/tests/g-icon on win32.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Rather than defining _WIN32_WINNT only in a handful of files, define
it in config.h, like we do with _GNU_SOURCE.
(Also remove a "#define WIN32_LEAN_AND_MEAN" that isn't really all
that useful.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c
Pointed out on IRC by Paweł Forysiuk.
https://bugzilla.gnome.org/show_bug.cgi?id=669330
This is implemented by with statfs_buffer.f_bavail (free blocks
for unprivileged users) as a default way to retrieve real free space.
Based on a patch by Marcus Carlson, bug 625751.
- getmntinfo can take struct statfs or statvfs depending on the
OS. Use getvfsstat and if not found getfsstat instead. Idea from
Dan Winship.
- g_local_file_query_filesystem_info(): use statvfs.f_fstypename
if available
https://bugzilla.gnome.org/show_bug.cgi?id=617949
- move choice of statfs vs statvfs from gio/glocalfile.c to configure.ac
- if statvfs is the choice, then don't check number of arguments to statfs()
- use choice in gio/gunixmounts.c as well
https://bugzilla.gnome.org/show_bug.cgi?id=617949
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.)
Introduced a more precise error message for EPERM when symlinking to
a local filesystem.
EPERM on symlink means symlinking is not supported by the underlying
fs so it is not the general meaning of EPERM which roughly translates
to 'Operation not permitted'.
GFile allows for the possibility that external implementations may not
support thread-default contexts yet, via
g_file_supports_thread_contexts(). GVolumeMonitor is not yet
thread-default-context aware.
Add a test program to verify that basic gio async ops work correctly
in non-default contexts.
http://bugzilla.gnome.org/show_bug.cgi?id=579984
This implements all the GIOStream file ops for local files.
We use the "fallback to output stream" for all GFileIOStream ops.
Some helpers stuff was added to the local input and output streams
so they could be reused.
When returning a filesystem type id, say "ext3/ext4" instead of "ext3",
since both use the same superblock magic, so we can't discriminate
them without more work.
Sometimes it seems like the trash dir and the file are on the same
filesystem but the rename fails with EXDEV anyway (can happen
e.g. with bind mounts or multiple mounts of the same device). In this
case we want to return the right error so that apps can fallback to
regular delete.
2009-03-03 Alexander Larsson <alexl@redhat.com>
* glocalfile.c (g_local_file_query_filesystem_info):
Handle filesystems no supporting reporting how much is free.
This fixes bug 573454 where the filesystem not supporting this
is the gvfs smb backend over the fuse filesystem.
svn path=/trunk/; revision=7951
2008-12-09 Alexander Larsson <alexl@redhat.com>
Bug 515777 - incorrect date&time on copy
* glocalfile.c:
(g_local_file_class_init):
Copy mtime by default
* gfile.c:
Change docs about G_FILE_COPY_ALL_METADATA to not mention
mtime as an example.
svn path=/trunk/; revision=7738
names
* glocalfile.c (g_local_file_set_display_name): Correctly set
error conditions if the new name is e.g. too long. Reported
by Leonardo Ferreira Fontenelle.
svn path=/trunk/; revision=7696
2008-09-30 Tor Lillqvist <tml@novell.com>
* glocalfile.c (get_volume_for_path) [Win32]: Avoid a
g_critical(). Pass a large enough result buffer to
GetVolumePathNameW(). Just use MAX_PATH.
svn path=/trunk/; revision=7561
2008-08-08 Loïc Minier <lool@dooz.org>
Bug 535124 – umask 002 not being applied for new directories, new
files get the correct umask
* glocalfile.c: (g_local_file_make_directory): Use 0777 instead of
0755 as umask
svn path=/trunk/; revision=7323
2008-07-01 Cody Russell <bratsche@gnome.org>
* gio/gioenums.h:
* gio/giotypes.h:
Moved all relevant typedefs into these files.
* gio/*.[ch]:
Updated wrt added files.
Split types into separate file for easier maintainership. (#538564)
svn path=/trunk/; revision=7127
2008-06-16 Tor Lillqvist <tml@novell.com>
Bug 538362 - Get Win32 icons back in the file chooser
* gcontenttype.c (g_content_type_get_icon): Look up the icon
corresponding to a file extension in the Registry. Patch by Hans
Breuer.
(get_registry_classes_key): Handle also REG_EXPAND_SZ type values.
2008-06-16 Tor Lillqvist <tml@novell.com>
Patches by Hans Breuer:
* glocalfile.c (is_xp_or_later): Handle compiling against older
SDK headers with missing VerifyVersionInfo(). Conditioned on
_MSC_VER, but should probably use some better test.
* glocalfile.c (g_local_file_query_filesystem_info): Don't test
uninitialised statfs_result variable on Win32.
svn path=/trunk/; revision=7049
2008-06-16 Michael Natterer <mitch@imendio.com>
* *.c: chain up unconditionally in finalize() and dispose(). Also
don't dereference these function pointers when calling them since
that has no meaning at all.
svn path=/trunk/; revision=7048
2008-06-16 Ross Burton <ross@burtonini.com>
Bug 536252 – GFileEnumerator should allow access to the containing
GFile
* gio/gfileenumerator.c:
* gio/gfileenumerator.h:
* gio/gfile.h:
Add g_file_enumerator_get_container() and a container writeable
construct-only property. Also shuffle around typedefs to make it
compile.
* gio/glocalfileenumerator.c:
* gio/glocalfileenumerator.h:
* gio/glocalfile.c:
Instead of a string filename take a GFile in the constructor and
use it to set the container property.
* gio/gio.symbols:
* docs/reference/gio/gio-sections.txt:
Update with new API.
svn path=/trunk/; revision=7044
2008-05-27 simon.zheng <simon.zheng@sun.com>
* configure.in: Fix#533369. Check whether memeber statvfs.f_basetype
available or not.
* gio/glocalfile.c: (g_local_file_query_filesystem_info):
Fix#533369. Make G_FILE_ATTRIBUTE_FILESYSTEM_TYPE work on Solaris.
svn path=/trunk/; revision=6939
2008-03-28 Alexander Larsson <alexl@redhat.com>
* glocalfile.c (g_local_file_move):
Reuse old string instead of adding new one.
svn path=/trunk/; revision=6762
2008-03-27 Alexander Larsson <alexl@redhat.com>
* glocalfile.c (g_local_file_move):
Return G_IO_ERROR_IS_DIRECTORY, not G_IO_ERROR_WOULD_MERGE when moving
file over directory. This is according to the docs and what the move via
copy+remove fallback does.
svn path=/trunk/; revision=6758
2008-03-14 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
(g_local_file_query_filesystem_info):
Use right define name for f_fstypename member check
2008-03-14 Alexander Larsson <alexl@redhat.com>
* configure.in:
Add required includes for f_fstypename member check.
svn path=/trunk/; revision=6703
2008-03-11 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
* glocalfileinfo.[ch]:
Correctly implement can_trash by actually
looking for a trash dir, not just assuming
one exists.
svn path=/trunk/; revision=6679
2008-03-08 Tor Lillqvist <tml@novell.com>
* glocalfile.c: Define FILE_READ_ONLY_VOLUME if it is missing from
winnt.h. (#521145)
svn path=/trunk/; revision=6643
2008-03-07 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
(g_local_file_query_filesystem_info):
Use struct statfs.f_fstypename if availible (e.g. on OpenBSD)
Patch from Jasper Lievisse Adriaanse
svn path=/trunk/; revision=6638
2008-02-25 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
Implement trashing and filesystem::readonly for win32 (#517235)
Patch from Yevgen Muntyan
svn path=/trunk/; revision=6578
2008-02-21 Alexander Larsson <alexl@redhat.com>
* gfile.[ch]:
* gio.symbols:
Add new g_file_has_prefix that does the same as g_file_contains_file.
Deprecate g_file_contains_file and add a macro that converts
it to g_file_has_prefix.
The reason for this change is that the contains_file() name seems to
imply that this does more work than what it does, but its really only
a name match (from #517086)
* gdummyfile.c:
* glocalfile.c:
* tests/g-file.c:
Update to match the above change.
svn path=/trunk/; revision=6546
2008-02-18 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
* glocalfileinfo.c:
* glocalfileoutputstream.c:
Use g_unlink/g_rename instead of unlink/rename;
do not pass raw filenames to g_set_error. (#517239)
Patch from Yevgen Muntyan.
svn path=/trunk/; revision=6533
2008-02-18 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
* glocalfileoutputstream.c:
Open files with O_BINARY on windows. (#517140)
svn path=/trunk/; revision=6531
2008-02-14 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
Copy permissions with file on copy (#514084)
This is what cp does and makes sure e.g. the
exec permissions are kept.
Its kinda weird in that it keeps the permission bits
the same while the uid and gid are different. However
the new uid is the user so its not a security issue,
and I've heard no complaints about cp on this issue.
svn path=/trunk/; revision=6514
