From: Marcelo Galvão Póvoa <marspeoplester_at_gmail.com>
Date: Fri, 11 Mar 2011 13:40:24 -0300

On 9 March 2011 21:31, Jonathan Gordon <jdgordy_at_gmail.com> wrote:
> On 9 March 2011 19:52, sideral <asieoniezi_at_gmx.net> wrote:
>>
>> I don't know what the person proposing unionfs had in mind.  To me it's
>> not clear whether he'd want multiple volumes exposed as one at the
>> storage layer (exposing only one block device over USB), at the file
>> system layer (r/w or r/o?), or in the file browser.  But I for one would
>> be quite happy with a read-only union file browser.
>>
>> sideral
>>
>>
>
> The past discussions have mostly been around 2 different ideas to
> solve the issue with music on the microSD card.
> 1) make the database handle per-device databases which get un/merged
> when cards are inserted/removed
> 2) actually mount the removable card differently (much more like
> unionfs on linux) so you could have /Music which shows all
> files/folders under /<internal>/Music and /<external>/Music (with
> read/write priorities which 'make sense')
>
>
> It shouldn't be surprising that the people wanting the first option
> use the DB and the people wanting the 2nd don't. So both would be the
> best outcome. I think 2 is relativly simple and is not a GSoC project
> by itself.
>
> A possible way to do 1 would be storing the cards serial number with
> the filename and making the browser hide tracks which are not on the
> inserted card or internal. Then you have the fun of needing a way to
> really remove tracks which havnt been seen in "ages", and deciding if
> two tracks on diferent cards are indeed the same, etc.
>
> Jonathan
>
>

Who would be the possible mentor for this project? It seems we have
many ways to tackle the problem, with varying degrees of difficulty.
Maybe we can try to figure out which are the main priorities here and
see what is reasonable to do.

Marcelo
Received on 2011-03-11