[gcmd-dev] Re: volume label

[koos]

Hello, 

I suppose I did this proposal too premature. I didn't realise at first
that it may be harmfull to the performance of gnome-commander. Perhaps
it is better to reconsider the updating the volume label when the
performance of gnome-commander has improved. Currently, when deleting
e.g. 10 files from a 100 file-directory takes a long time, because
after each deletion the file-list and the file-selector are updated.

koos

On Thu, 10 May 2007 18:56:24 +0200
Piotr Eljasiak <address@hidden> wrote:

> > 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
> 
>