Comment 8 for bug 153054

I am not sure about the database structure, but making the following
assumptions:
1) Library path is included as a field
2) A filter can be written such that an sql select statement with the
library path as a constraint would make those files invisible to all
operations (add to playlist, play, random etc).

Then the user can be given the option to select which libraries are dynamic.
During startup exaile checks to see if this library destination is mounted.
If it is, display the contents, if not use the above proposed filter (sql).
Since if both 1 and 2 above are true, there would not be a need for tracking
deletions of already invisible material. This task can be deferred until the
next start up.

The issue I can immediately see is what happens if the library path was
mounted during start up but then goes away (like removel of storage device
of NFS failure) but that issue is already present I think. It would not be
an additional problem due to adding this feature.

I disagree with tobyS's idea of running a daemon in the background which I
think is a bit too much for this minor feature. However if the "filter" idea
can be loaded with more features, this idea might be revisited.

Also, I do agree this is a minor feature - but one that nobody is
implementing as far as I know. So it's a "nice to have" feature.

Best regards,

On Thu, Oct 16, 2008 at 1:28 PM, Aren Olson <email address hidden> wrote:

> Well, basically its a question of how to sanely detect and handle the
> presence/removal of such drives, while also automatically handling
> actual file deletions. The current system is based exclusively on file
> paths. So while we could detect the separate filesystem when its
> mounted, once its unmounted there's no way to distinguish between
> deletion and being unmounted. This means that, for EVERY FILE we would
> have to store some identifier for what filesystem its on, and be able to
> know whether that fs is mounted/unmounted, and check all of those at
> start. Not very ideal, to say the least.
>
> Another way of handling it could be to just say that if you want a
> feature like this it must be registered as a separate library, which
> could be given a "not always present" mark or something like that. Then
> we just check files to be sure that their library is mounted (easy as
> the library path will be the same as the start of the file's path), and
> only if it is, should we attempt to handle the file. This is doable, but
> a fair chunk of work.
>
> Also, this is a use case that only affects a very small percentage of
> users and it is thus very low on the list of things to do. It's a
> legitimate concern, and is likely to be implemented eventually, but
> don't hold your breath. However, patches are, as always, welcome, as are
> additional ideas on how to best handle the detection and handling of
> mounts.
>
> --
> Dynamic Library (Do not display unavailable VOLUMES/DRIVES)
> https://bugs.launchpad.net/bugs/153054
> You received this bug notification because you are a direct subscriber
> of the bug.
>