[haiku-commits] Re: r40736 - in haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap: . imap_lib

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 02 Mar 2011 08:40:48 +0100

On 02.03.2011 04:18, Clemens wrote:
On Wed, 02 Mar 2011 03:36:01 +1300, Ingo Weinhold <ingo_weinhold@xxxxxx>

Does it also handle the case when a app want to open an arbitrary file
without knowing anything about "IMAP FS user@xxxxxxxx"?
Why would some app do that? At some point someone has to know what to
where. If that is supposed to persistent it could be done via
Unfortunately, at least ATM, that wouldn't work particularly well with

How does auto mounting works exactly? Does it blocks in the boot script
till everything is mounted?

Yes, since I've introduced the mount_server for exactly that purpose. Previously Tracker did the mounting and this had exactly the problem that sometimes a relied on volume was not available yet.

I had the case in mind that mounting a lot of "service"-fs may takes a
significant amount of time and it should be done asynchronously.

It probably depends.

Imagine this: For some stupid reason you opened a mail in StyleEdit.
Because you also have some kind of session manager StyleEdit attempt to
open the mail after a reboot. StyleEdit does not know about imap service
at all. Because the imap-fs is mounted asynchronously the mail is not
there and StyleEdit throws an error. Think this asynchronous case can
only be handled with a lazy mount (?)

On the other side I don't know if it is the best user experience when
StyleEdit hangs for several time till imap-fs is mounted...

Maybe it's possible to mount more than one FS concurrently, if they don't have dependencies on each other... but one can't have it all. I don't see why mounting can't be made very quick. The only FS on Haiku which I am aware of that mounts slowly is NTFS. IMAP FS should cache all mails locally anyway, so why can't it be quickly mountable...

Best regards,

Other related posts: