pytagsfs team mailing list archive

[Forest Bond <forest@xxxxxxxxxxxxxxxxxxx>]

Hi Raph,

Sorry it too me so long to get back to you.

On Fri, Jul 08, 2011 at 12:36:30PM +0200, Raphaël wrote:
> On Sun, Jul 03, 2011 at 02:56:35PM -0400, Forest Bond wrote:
> > 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.
> 
> Attached the code in it simplest form.
> (also attached to #742649)

Thanks, I've applied this and pushed it up to the dev branch in Launchpad.

> > 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.
> 
> If you can point be to the right part of the code I would be happy to
> provide such a patch if I can (for the "rm <file>" implementation too).

We would need to implement the "unlink" method on FileSystemMappingToRealFiles.

> > > $ 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.
> The last example above was misleading, I meant:
> $ cp -a ecology waste
> # admitting "ecology" is either not an existing tag in the mounted
> # filesystem, either it was filtered with "dstfilter".
> 
> In such case I would expected that every file tagged "ecology" would get
> the "waste" tag added. But if, sadly, fuse does not provide the necessary
> information I don't have opinion about available workarounds.

Like I said, this could be done using hard links.  Your copy command would look
like this:

  cp -lr ecology waste

For this to work, we'd need to implement the "link" method on
FileSystemMappingToRealFiles.

If you're interested in taking a look at this and/or unlink support (like you
mentioned above), you'll want to familiarize yourself with the following
classes:

* pytagsfs.fs.FileSystemMappingToRealFiles
* pytagsfs.sourcetreerep.SourceTreeRepresentation

And of course, let me know if you have questions.

Hope this helps.  Thanks again for your contributions.

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

Attachment: signature.asc
Description: Digital signature