Using directory separator ("/") inside conditional expression raises PatternSyntaxError

[Michael Helmling]

Hi,
if you try to use "conditional subdirectories", e.g.:
pytagsfs -o format='%a/%?%l/%?%t.%e' src dest

this throws a syntax error. Of course, in easy examples one can circumvent this by putting the / outside the condition:
pytagsfs -o ro,format='%a/%?%l%?/%t.%e'

since UNIX (and probably windows, too?) will ignore subsequent slashes, but in more complex scenarios this is not an option. I would have loved to submit a patch to fix this, but I have no chance in understanding how subspat.py works. ;-)

Regards,
Michael

[Forest Bond (forest-bond)]

Hi,

There's probably a bit more to this than you might think. The complications all come from renames; pytagsfs needs to know which tag field to update. With paths that vary by number of directory segments, this gets trickier. It seems possible, but it is not implemented now.

-Forest

[Michael Helmling (supermihi)]

That indeed sounds reasonable. In fact, up to now I wasn't aware of the renames feature of pytagsfs - pretty cool stuff. :-) However I'm afraid this makes my suggestion impossible to implement in a consistent manner, since in theory you could, for example, have fancy cases such as a name appearing both as composer and artist, so there would be no way to deterministically decide what the user did mean.

Still, I find this very sad, because pytagsfs is extremely useful even if you use it only "in one direction", i.e. mounting read-only, in which case the above doesn't harm. What about allowing slashes inside conditions if the -r option is set? Would this be easy to implement?
At least, I think pytagsfs shouldn't throw a SyntaxError but display a short explanation about what's going on, to preserve the user from checking his format string again and again.

kind regards,
Michael

[Forest Bond (forest-bond)]

Hi,

Thanks for the report, by the way.

On Mon, Jun 15, 2009 at 09:28:50PM -0000, Michael Helmling wrote:
> That indeed sounds reasonable. In fact, up to now I wasn't aware of the
> renames feature of pytagsfs - pretty cool stuff. :-)

Glad you think so. ;)

> However I'm afraid this makes my suggestion impossible to implement in a
> consistent manner, since in theory you could, for example, have fancy cases
> such as a name appearing both as composer and artist, so there would be no way
> to deterministically decide what the user did mean.

The specific case that you mention is non-ambiguous, and is possible. I agree
that there are other more complicated cases that are ambiguous. pytagsfs could
conceivably detect patterns that could result in ambiguous renames and either
reject them or warn the user that renames might not yield the expected result.

> Still, I find this very sad, because pytagsfs is extremely useful even if you
> use it only "in one direction", i.e. mounting read-only, in which case the
> above doesn't harm. What about allowing slashes inside conditions if the -r
> option is set? Would this be easy to implement?

Possible, but not easy because it requires deep modification that runs all the
way from the UI and down into subspat.py (and probably elsewhere, too). It'd be
a fun project. ;)

> At least, I think pytagsfs shouldn't throw a SyntaxError but display a short
> explanation about what's going on, to preserve the user from checking his
> format string again and again.

I absolutely agree. Would you mind filing a separate bug for this?

As always, patches are welcome. I hope to make a 0.9.1 release soon, but I'm
shorter on time than I've ever been due to starting a business, so I can't say
I'll be able to do any real work on pytagsfs right away.

BTW, I've never tested using conditional format strings that could result in
empty directory names. I'm curious if that should be disallowed because it may
cause problems for renames, but I don't really know. I'd like to add some unit
tests covering that scenario (another item for the large-and-growing todo
list!).

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org