search for: namespace_

I'm in the process of upgrading an old server which is running uw-imap to a new one running Dovecot. With the old machine, unfortunately, my users had the opportunity to store their e-mails in various locations. For example, some have their mail boxes stored in ~/mail/[various mbox files], others ALSO have a ~/mail/clients/[various mbox files] and yet others simply stored them in their

I've just noticed that Dovecot 1.0-stable and 1.0-test78 don't include mbox folders with names beginning with "." in the IMAP LIST output. These are often used to store "hidden" folders for storing things like IMAP client configuration (e.g. Pine 4.x, IMHO, Prayer). Usually the user shouldn't be able to see these, but there are occassions when they might. It seems

Hi all. Can any C programmers out there tell me how to fix Dovecot to default to Maildir format when autodecting can't find anything? I don't know C, but it seems like it would be a simple thing. Right now, I use the autodetect mailbox feature because we want users to choose to optionally be able to use Mbox format (we have some diehard unix users with non-maildir clients). I have

Hi! With dovecot 1.x, I was using a post-login script to dynamically add shared mailboxes using NAMESPACE_X.. environment variables, based on filesystem permissions: After login, the post-login script was executed with user permissions (mail_drop_priv_before_exec=yes). It added all subdirectories of "/var/spool/mail/Shared" as namespaces for which the user had write permissions. E.g.: NAMESPA...

In http://www.dovecot.org/list/dovecot/2006-December/018253.html Timo Sirainen wrote > > You can still change NAMESPACE_* environments. I don't remember how > exactly now, but you can do eg. "set > /tmp/sets" in the script, see > what it has set and modify them in the script. in response to my query regarding setting the mail_location in namespaces from a mail_executable script. The purpos...

Hi! I've been using shared mailbox trees using maildir, unix permissions and separate namespaces per shared tree since dovecot 1.0. However now that I've upgraded to 1.2.8, I cannot create subfolders anymore. The server responds with "NO Invalid mailbox name: test/testsub". The hierarchy separator for the namespaces is / because I am mixing maildir and mbox namespaces and

...ot; setting for namespaces, which sounded like it might address this problem. However, putting that setting into dovecot.conf causes it to fail to start with a "Unrecognized config option" error, and using an imap_executable wrapper that sets the env variable as specified in the code (NAMESPACE_<number>_SUBSCRIPTIONS) sets it, as I can see from the dovecot log output: Namespace: type=private, prefix=~/mail/, sep=/, inbox=no, hidden=yes, subscriptions=yes But doesn't seem to have any effect. These two things combined lead me to believe this option was deprecated at some point...

Dear list, It seems that S4 methods defined for an S3 'base' generic are not used in 'base' functions. This can be problematic when 'base' functions start with something like 'as.matrix'. ### START R code setClass("classA", contains = "matrix", representation(realData = "numeric")) setMethod("as.matrix",

...ct, subobject, base class subobject, array element, variable, function, instance of a function, enumerator, type, class member, template, or namespace. Now, you ask, how can we be sure these have no linkage across translation units, because: 3 A name having namespace scope (_basic.scope.namespace_) has internal linkage if it is the name of --an object, reference, function or function template that is explicitly declared static or, We know that they do not denote the same object because the rules that guide us when they do are not met: 9 Two names that are the sa...

On Oct 15, 2008, at 6:58 AM, Tatu Vaajalahti wrote: >> Yes, but why do you think they should get a different address? I can >> understand that it is surprising that they do, but determining >> whether >> this is legal or not requires reading the language standard. >> Hopefully >> a language lawyer can chime in and say whether this transform is >>

On 15.10.2008, at 16.43, Duncan Sands wrote: >> True, but note that it is the address of a variable that is used, not >> the value. > > Yes, but why do you think they should get a different address? I can > understand that it is surprising that they do, but determining whether > this is legal or not requires reading the language standard. > Hopefully > a language

This feature is roughly finished now, although it needs a few more tests and some examples. It's pretty much up to par with all the other bindings, but it lacks a completely safe AIO buffer. It won't stop you from freeing the buffer too early) because golang's GC inexplicably lacks a way to declare a root from C. I can probably do it with a global variable and ref counting on the

Now runs a complete set of tests, notably including the AIO test. File descriptors are passed in and out as plain ints (instead of *os.File) for a couple of reasons: (1) We have to pass the plain int to syscall.Select. (2) Turning an fd into an os.File causes golang to set the blocking flag which is deeply unhelpful. Rich.