Just because you have 1 or 2 people asking to use a stupid PERIOD in a mailbox name does not merrit a demand or real reason to allow the period.

Let em to use an underscore or dash ( _ - ) sheeesh! Is it worth the bother to redefine your code for that?

hehe

--- Timo Sirainen <tss@iki.fi> wrote:

On Tue, 2006-08-22 at 02:32 +0300, Mikko Kortelainen wrote:

...

Hi,

There's been some demand from users to make it possible to use the period character (.) in folder names, but that is impossible when the folder separator is already period.

Is there any possibility of replacing that which another separator, say a / ?

Currently Dovecot supports only Maildir++ directory layout, which specifies that '.' character is used as the separator in the filesystem. You can change that separator from the sources, but then you'll have to rename all the existing maildirs.

src/lib-storage/index/maildir/maildir-storage.h MAILDIR_FS_SEP and MAILDIR_FS_SEP_S

On Tuesday 22 August 2006 05:56, Mikko Kortelainen wrote:

I wouldn't say that. If people want to sort their mail by making a folder for each sender they have a lot of correspondence with, creating a folder named 'mikko.kortelainen@techelp.fi' is a lot more intuitive than 'mikko_kortelainen@techelp_fi'. For you or me it probably wouldn't matter, but I'm talking about normal users here...

I consider myself a normal user and I would have no difficulty using a '_' as opposed to a '.' in folder names. In fact, I never use a '.' in folder names. I reserve that for file name exclusively.

Just my 2¢.

-- Gerard Seibert gerard@seibercom.net

We give advice, but we cannot give the wisdom to profit by it.

La Rochefoucauld

Often (I guess) people are transferring to dovecot from uw-imapd which allows "." in mbox names. Lots of staff here teach courses called something like 53.101, 47.897 etc, so periods are very common in mbox names.

To facilitate painless (for users anyway) transition to dovecot, I set the maildir folder separator to ';' and it works just fine.

To me it makes the most sense to use a character that is least likely to be used - a semi-colon sounds good to me.

It would be nice if this were a config. file option - how hard is this to change for a 'non-programmer'?

--

Best regards,

Charles

On Tue, August 22, 2006 4:58 pm, Kenneth Porter wrote:

Does this character ever show up in UI's? Do end users even need to know about it? If not, can it be outside the printable set? If so, a vertical tab might be a good default.

I don't believe the user ever sees the folder separator. However, it would be nice to have a 'typable' character so when you're dealing with the filesystem hierarchy from a shell, it would be easier to view and navigate.

I vote for a configuration file option. I'm not sure how feasible it would be to change the default at this point since it would break everyone's existing installations.

The Maildir++ documentation at http://www.inter7.com/courierimap/README.maildirquota.html shows an example of a colon being the separator:

"Can folders have subfolders, defined in a recursive fashion? The answer is no. If you want to have a client with a hierarchy of folders, emulate it. Pick a hierarchy separator character, say ":". Then, folder foo/bar is subdirectory .foo:bar."

A tilde might work well also. The directory on the disk could be called ".Folder1~Folder2~Folder3".

I don't normally create folders with dots in them, but there have been times in the past when I've tried to and couldn't.

-Vince

On Tue, 2006-08-22 at 18:11 -0700, Vince Valenti wrote:

I vote for a configuration file option. I'm not sure how feasible it would be to change the default at this point since it would break everyone's existing installations.

The Maildir++ documentation at http://www.inter7.com/courierimap/README.maildirquota.html shows an example of a colon being the separator:

"Can folders have subfolders, defined in a recursive fashion? The answer is no. If you want to have a client with a hierarchy of folders, emulate it. Pick a hierarchy separator character, say ":". Then, folder foo/bar is subdirectory .foo:bar."

Oh. I was sure that it had said that '.' character was the required separator. Guess I just assumed that because of Courier. So, since the spec doesn't require it to be '.', I could add a configuration option for it. Not sure if I'll do it before v1.0..

In any case the separator that is sent to clients can be different than the real separator in disk. That way you could use some weird character in the disk, but show user/client a nice standard '/' separator.

On Tue, Aug 22, 2006 at 06:13:57PM -0700, Vince Valenti wrote:

On Tue, August 22, 2006 4:58 pm, Kenneth Porter wrote:

...

Does this character ever show up in UI's? Do end users even need to know about it? If not, can it be outside the printable set? If so, a vertical tab might be a good default.

I don't believe the user ever sees the folder separator. However, it would be nice to have a 'typable' character so when you're dealing with the filesystem hierarchy from a shell, it would be easier to view and navigate.

The user sees the separator if they're using a local MUA on the same mail hierarchy as Dovecot.

Also most IMAP MUAs surely tend to show the same separator that the IMAP server uses don't they?

-- Chris Green (chris@halon.org.uk)

Jason Fesler wrote:

You'd want a character that *can* be typed and used for people using procmail. :-)

I kind of think that procmail is not as relevant in today's mail environment as it once might have been. I guess you do have to keep a semblance of compatibility though.

-- Gerard Seibert gerard@seibercom.net

On August 23, 2006 7:43:44 AM -0500 "/dev/rob0" <rob0@gmx.co.uk> wrote:

On Wednesday 23 August 2006 07:34, Gerard Seibert wrote:

...

...

You'd want a character that *can* be typed and used for people using procmail. :-)

I kind of think that procmail is not as relevant in today's mail environment as it once might have been. I guess you do have to keep a semblance of compatibility though.

I still use it ... "it ain't broke" so I didn't fix it.

But it is broke ... I can't tell you how many times someone wrote a stupid procmail script that eats all cpu, breaking mail for everyone. (once is enough).