On Thu, 2009-11-26 at 00:20 +0100, Jannis Pohlmann wrote: > Hey, > > gtk-app-devel-list might be the better place for it but I'll try > asking > here first. Hope that's ok. Well, either would work i guess, as most gio developers are on both. But i think techincally gio API issues go on gtk-devel-list. > One thing that stopped working in the Thunar file manager after I > ported it to GIO instead of ThunarVFS is that the free space in the > status bar and properties dialog is no longer updated properly. The > reason for this is that prior to this, file change events were emitted > by ThunarVFS whenever the free space on the device changed (at least > that's what I assume because the progress dialog label was only > updated > on file change events). > > So, I wonder what the easiest way to monitor the free space on a > device > is (assuming that we have a GFile for a file or directory and the free > space we're interested in is that of the volume/mount the > file/directory > is located on)? > > There is g_file_get_filesystem_info() but that information cannot be > monitored. There are no file change events emitted from the > GFileMonitor of files/dirs when the free space of their enclosing > volume/mount changes. So, my next idea would be to listen to > the "changed" signal of enclosing volumes/mounts? But is this the > correct/best way and does it work at all? This is not currently possible, file monitor monitors a specific path/directory, and g_file_get_filesystem_info() is essentially statfs/statvfs, so its a "polling" mechanism. However, even if we wanted to add an API for something like this there is no reasonable implementation on the lower level. Free space for a filesystem change with almost every write operation on the system, and there currently is no way to monitor all writes on a filesystem. Additionally, I don't think you really *want* to monitor this. The monitor would probably trigger thousands of times a second when you're e.g. compiling something. And the result is just a minor change in the free space that probably won't even show a change in the rounded value of the free space shown in the status bar. So, it seems to me that polling the free space regularly (every minute or something) is a better way to do this than a monitor. Of course, polling might run the risk of spinning up the HD if spun down, but I *think* that will be returned from the kernel cache (needs testing).
Attachment:
signature.asc
Description: This is a digitally signed message part