Re: Gvfs metadata handling on removed / new files

[Nelson Benítez León <nbenitezl gmail com>]

Ok, I agree with you it's an acceptable drawback given it cannot
detect if an external program deletes a file, but still gvfs could do
some things to improve situation:

 - Discard existing metadata when a new file is created by Gvfs. To reproduce:

[inf@fedora16 ~]$ touch gnu
[inf@fedora16 ~]$ gvfs-set-attribute -t string gnu metadata::myprop yeah
[inf@fedora16 ~]$ gvfs-info gnu | grep metadata
  metadata::myprop: yeah
[inf@fedora16 ~]$ rm gnu
[inf@fedora16 ~]$ echo "holadola" | gvfs-save gnu
[inf@fedora16 ~]$ gvfs-info gnu | grep metadata
  metadata::myprop: yeah

Because the one who creates the file is Gvfs it can be sure the file
was not existent before and so discard existing internal metadata.

- Offer new api to purge existing metadata about deleted files:

This is the nautilus case, gvfs can't watch all files to monitor
removes as you said, but nautilus does it for the files it's managing,
and when a file is externally removed nautilus receives an event, the
problem is nautilus cannot then erase the metadata of that file
because file is already removed, if gvfs offered an api to erase the
metadata of a file regardless of whether that file exists or not that
would help to easy fix http://bugs.gnome.org/45953

If gvfs maintainers think that api makes sense I can file a bugzilla
enhacenment about it..


Thank you!


2011/12/13 Tomas Bzatek <tbzatek redhat com>:
> Hi Nelson,
>
> interesting issue, indeed. I'd say not using GIO file operations will
> always get you out of sync. Same situation when you move
> files/directories manually, gvfs metadata won't be updated.
>
> AFAIK gvfs metadata system was designed for non-critical data storage
> such as emblems, icon positions, custom notes etc and such non-standard
> situation is probably an acceptable drawback. Alex would know more
> though.
>
> Thinking about it, there's a possibility to use xattrs and link back to
> gvfs-metadata database with an unique ID. Xattrs are usually part of an
> inode and are removed together with a file (unless it's hardlinked). The
> downface is that xattrs are still not common these days, not all widely
> used filesystems support them by default or are intentionally turned off
> by default.
>
> Monitoring is not easily possible since number of inotify slots is
> limited and you can't really watch everything. I'd be interested how
> tracker (or even zeitgeist?) do monitor changes on those big number of
> folders.
>
> --
> Tomas Bzatek <tbzatek redhat com>
>
> On Fri, 2011-12-09 at 11:01 +0100, Nelson Benítez León wrote:
>> Hi,
>> while resolving nautilus regression http://bugs.gnome.org/45953 I've
>> come across an gvfs behaviour that I would like to ask you if it's a
>> correct or not.. the thing is:
>>
>>  file ~/Desktop/foo has some metadata (eg. stored by nautilus)
>> rm ~/Desktop/foo
>> now you create a new file on ~/Desktop/ with same name, a new ~/Desktop/foo
>> this new ~/Desktop/foo carries the same metadata values as the old one.
>>
>> that is.. because the file wasn't deleted with g_file_delete() but
>> with rm then the metadata wasnt removed from internal gvfs, so when a
>> new file is created in the same path and name, that file automatically
>> has the same metadata values of the old removed file.
>>
>> Is this a gvfs bug on handling removed/new files? if true, could it be fixed by:
>> - gvfs monitoring external removes and delete metadata accordingly?
>> - or better yet,  by discarding existent metadata when adding a new
>> file that comes from external remove/add ?
>>
>>
>> To reproduce it:
>>
>> [inf@fedora16 ~]$ touch foo
>> [inf@fedora16 ~]$ gvfs-set-attribute -t string foo metadata::myprop yeah
>> [inf@fedora16 ~]$ gvfs-info foo | grep metadata
>>   metadata::myprop: yeah
>> [inf@fedora16 ~]$ rm foo
>> [inf@fedora16 ~]$ gvfs-info foo | grep metadata
>> Error getting info: Error stating file '/home/inf/foo': No such file
>> or directory
>> [inf@fedora16 ~]$ touch foo
>> [inf@fedora16 ~]$ gvfs-info foo | grep metadata
>>   metadata::myprop: yeah
>> [inf@fedora16 ~]$ gvfs-info foo | grep metadata
>>
>>
>> Thanks!
>> _______________________________________________
>> gvfs-list mailing list
>> gvfs-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gvfs-list
>
> _______________________________________________
> gvfs-list mailing list
> gvfs-list gnome org
> http://mail.gnome.org/mailman/listinfo/gvfs-list