gcmd-devel
[Top][All Lists]
Advanced

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

[gcmd-dev] Re: volume label


From: Piotr Eljasiak
Subject: [gcmd-dev] Re: volume label
Date: Thu, 10 May 2007 18:56:24 +0200

> Here's another patch. I hope you like it.
> It updates the volume label more often (the label that indicates how
> much disk space is left). It is now updated after a file is created,
> deleted or changed. Previosly this was only done after changing to
> another directory or reloading the filelist.

While I like the idea of real-time updating 'free space' volume label,
I'm afraid it's not that simple. gcmd relies heavily on
gnome-vfs-monitor
(http://developer.gnome.org/doc/API/2.0/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs
-monitor.html) - all changes to monitored directories result in sent
signals:

1. GNOME_VFS_MONITOR_EVENT_CREATED
2. GNOME_VFS_MONITOR_EVENT_CHANGED
3. GNOME_VFS_MONITOR_EVENT_DELETED

These signals are dispatched respectively to
(gnome-cmd-file-selector.cc):

1. on_dir_file_created ()
2. on_dir_file_changed ()
3. on_dir_file_deleted ()

Handling these signals is relatively cheap now, for all activity is done
on internal gcmd lists and is ended with call to update of file label
(status line: "%s of %s kB in %d of %d files"). Adding an extra
update_vol_label() here, which in fact is a call to
gnome_vfs_get_volume_free_space (), may be
very harmful to app's performance.

Please start gcmd from console with set -d=n flags to see how much
activity is reported during copying, moving or just merely renaming of
files. And what will happen if we perform actions on files en masse
(like mass file renaming)?

So conclusions... 

Updating volume free space is

1. virtually unnecessary during file creation stage, for we need *final*
information on disk free space ;o)
2. performance killer - so definitely no for
GNOME_VFS_MONITOR_EVENT_CHANGED handling
3. a maybe for file deletion

There are 2 strategies for real-time updating of volume label coming to
me at the moment.

A. updating volume label after each GNOME_VFS_MONITOR_EVENT_DELETED -
that should not very expensive
B. updating volume label after each copy and delete action

The latter one has even an additional advantage - we could get rid of
annoying file list 'flickering' during batch file operations (like mass
file renaming)


Piotr






reply via email to

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