← Back to team overview

pytagsfs team mailing list archive

Re: xattr metastore: an initial attempt

 

Hi Raph,

On Wed, Jun 22, 2011 at 01:32:37PM +0200, Raphaël Droz wrote:
> On Sat, Jun 04, 2011 at 04:20:19PM -0400, Forest Bond wrote:
> > The pytags utility was a bit of a hack and was written specifically for mutagen
> > rather than as a general front end to the pytagsfs MetaStore API.  We have
> > changed this, so now it supports arbitrary metastores.
> you're right, pytags now works and XattrMetaStore is cleaner !

Yes, your implementation is looking pretty good now.  If you clean things up a
bit I can include this.

> So:
> $ listattr() { for i in *.avi; do for j in $(attr -ql $i); do echo "$i ($j = $(attr -q -g $j $i))"; done; done; }
> $ listattr 
> Argentina_history.avi (subject = history)
> Jaffa_Palestine.avi (subject = palestine,orient,history)
> Nuclear_wastes.avi (subject = ecology)
> 
> # these files all use the 'subject' attribute to store multiple values
> separated by commas.
> 
> PYTHONPATH=modules ./pytagsfs -ds	\
> 		   -o metastores='pytagsfs.metastore.xattr_.XattrMetaStore;pytagsfs.metastore.path.PathMetaStore'   \
> 		   -o format='/%{subject}/%f' ~/tagsfs/sources ~/tagsfs/mnt/
> [ a bit cleaner xattr_.py attached ]
> 
> $ tree mnt/
> mnt/
> ├── ecology
> │   └── Nuclear_wastes.avi
> ├── history
> │   ├── Argentina_history.avi
> │   └── Jaffa_Palestine.avi
> ├── orient
> │   └── Jaffa_Palestine.avi
> └── palestine
>     └── Jaffa_Palestine.avi
> 
> 
> * I can rename a tag (= directory):
> $ mv history economy
> * I can change (= move) the tag of a file:
> $ mv palestine/Jaffa_Palestine.avi ecology/
> * I can create a new tag and affect a file to it (if it replace another one):
> $ mkdir palestine && mv ecology/Jaffa_Palestine.avi palestine/
> 
> [ please note here that it would be nice if an empty directory (unused
> tag) stayed in the tree until the umount so it can be easily reused ]

Maybe this should be a command-line option.  Currently directories disappear
when they are emptied, but I can see that either behavior might be desirable.

> $ I can NOT add a new tag to a file (explanation below on how it is
> different than above):
> $ mkdir nuclear && cp ecology/Nuclear_wastes.avi nuclear/
> cp: cannot create regular file `nuclear/Nuclear_wastes.avi': Function not implemented
> [ attached as attempt1.log ]
> Consequence is that the following obviously does NOT work:
> $ mkdir waste && cp -a ecology waste
> `ecology' -> `waste'
> `ecology/Nuclear_wastes.avi' -> `waste/Nuclear_wastes.avi'
> cp: cannot create regular file `waste/Nuclear_wastes.avi': Function not implemented
> cp: failed to preserve ownership for `waste': Bad address
> # Also note that the same also applies with a "simple" cp -r.

Right, we can't support this via file copying because copying just creates a new
file with the same data as the existing file and the filesystem is never told
where the data comes from (i.e. the existing file's path).  This could be
supported with hard links, though.  I think that would be a very natural way to
add new tags to files.

> * I can not remove a tag by removing a file:
> $ rm economy/Argentina_history.avi
> rm: cannot remove `economy/Argentina_history.avi': Function not implemented
> [ attached as attempt2.log ]

Hm, I agree that this should be supported.

> I think that the impossibility to unlink is the root of the copy
> problems. Any hints about this ?

No, it is a distinct issue.  However, none of the above is something your
metastore needs to be concerned with.  These are both new features that can be
added to pytagsfs without making any changes to the metastore API.

Hope this helps.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com

Attachment: signature.asc
Description: Digital signature


Follow ups

References