uniqueid based paths (was: Minutes 16/3)

[Bron Gondwana]

On Mon, Mar 23, 2015, at 11:50 PM, Gerd v. Egidy wrote:
> > Tech support is another use case here.
> > 
> > People often call and say they can't find a message in this and that folder
> > or that some Kolab data is not up to date. We ssh into the machine
> > and then use f.e. midnight commander to browse the folders of the user.
> 
> Yes, that is a common use case. Being able to grep, du, copy or otherwise 
> script access to all folders of a user really speeds up support. You can 
> immediately see what the user has done with your natural tools on the 
> commandline.

This is becoming less and less the case over time, with things like
metpartition, and now archivepartition as well.  You wind up having to
go to multiple locations on disk just to find things (I know because I
get to do support on our servers too).

And then there's calendars where the "displayname" is an annotation and
the folder name is a UUID.  You basically need to have tooling that knows
the internals by then.

> > With uniqueid based paths, it won't be easy to use unix tools to grep
> > the message base of a single user only. You first need to filter
> > the list of folders and then limit your "view" to that folder list.
> > 
> > A tool that lists the user folder -> uniqueid based path
> > in a machine parsable way (=scriptable) might help here.

Definitely going to need that.

> How about a FUSE filesystem? Classic UNIX way of doing things: everything is a 
> file or directory. That way you could use all your tools the natural way 
> without any changes to them. Probably this should be read only and it should 
> have proper locking of it's access to mailboxes.db.

I can see that working... though you're almost a the point where you might as well
have a FUSE filesystem talking directly to the imapd by then - you could even mount
it remotely.

Bron.


-- 
  Bron Gondwana
  brong at fastmail.fm