Talk:Maildir

Latest comment: 7 years ago by James.cartwright.21 in topic does kmail really "support maildir directly"?

does kmail really "support maildir directly"?

edit

What is meant by "Software that supports Maildir directly"? That the software can read / write a maildir on a filesystem. From inspection, kmail does not appear to support this. How does one open a maildir in kmail? James.cartwright.21 (talk) 06:53, 24 May 2017 (UTC)Reply

requires a high number of inodes

edit

It should be noted somewhere that the maildir format requires a high number of inodes on your filesystem, which can become a big issue if you are planning to support a very high number of messages. --Thoric 15:44, 7 September 2006 (UTC)Reply

space-inefficient

edit

It is weird that the article does not discuss pros/cons of storing each msg in a separate file. If the filesystem has a large cluster size, this could be quite space-inefficient, which might matter if a large number of msgs are being stored. And is the first sentence correct or misleading? To what extent is this "only" a spooling format (temporary) vs. a long-term msg storage format? mbox is definitely used for long-term msg storage. So is maildir directly analogous, or just sort of similar, in usage/function? Do mbox-based systems like Eudora and Thunderbird use mbox formats for spooling of to-be-processed msgs? 69.87.201.163 00:03, 20 January 2007 (UTC)Reply

I agree that the article needs to discuss block sizes and the effect of using lots of small files, with a link to Comparison of file systems. As you point out, describing maildir as a "spool" file format does need to be re-phrased, as it is used for many IMAP servers. mbox vs maildir is a bit like vi vs emacs. Last weekend I created Category:E-mail storage formats in order to collate all of the formats, but I ended up getting a bit sidetracked wading through and reorganising Category:E-mail. A new article E-mail storage format may also be useful. John Vandenberg 05:33, 20 January 2007 (UTC)Reply

Needs Ads and Disads

edit

I've just done a basic cleanup and correction run. I agree with the above points, and I think they should be included in and Advantages/Disadvantages set of headings. There's a lot to go in there, including things that many people don't immediately think of, such as the possibilities of using standard filesystem tools for backup.

Zope3 uses Maildirs for delivery spools, someone might like to add an up-to-date summary. —The preceding unsigned comment was added by DanShearer (talkcontribs) 21:58, 1 February 2007 (UTC).Reply
Dan Shearer 21:58, 1 February 2007 (UTC)Reply

{{Infobox file format}}

edit

I would like to put an infobox on each email storage format, but {{Infobox file format}} doesnt suit maildir very well. Anyone know of other directory-centric formats that I could use to analyse this further. John Vandenberg 23:11, 1 February 2007 (UTC)Reply

Criticism

edit

The section "This analysis misconstrues the purpose of step 2." appears to break Neutral point of view (NPOV). This criticism seems to ignore multi-host environments in which PID and temporary file name can clash. A simple clarification of the kind that in a network environment with unique host IDs already taken in account on one host the following problems can still occur, would suffice.

StevenMcCoy 13:50, 18 July 2007 (UTC)Reply

Agreed; it also smells of 'original research'. In general, the criticisms are about certain *implementations* of maildir; the specification itself is fine -- it guarantees there are no name clashes. I think the criticism should be removed on the basis of the (1) 'no-original-research' rule, and (2) because the criticism is not relevant for the Maildir spec. A section might be added which discusses limitations of certain Maildir implementations, as long as that does not violate (1).
djcb Aug 2008 —Preceding unsigned comment added by 192.100.124.219 (talk) 07:42, 18 August 2008 (UTC)Reply
Right. My (Dovecot wiki's) criticism is about qmail (and its man page), and while it's also written by the original Maildir inventor, I don't think it should be considered an actual Maildir specification. That also made me realize the technical section also had some implementation-specific things said there as facts (and one of them wrong), so I went and changed them now. TimoSirainen (talk) 13:58, 19 August 2008 (UTC)Reply
Both the analysis and the writeup here are flawed: the writeup doesn't clearly differentiate what's analysis by Dovecot vs. the writeup here; the analysis itself seems ignorant of atomic tempfile creation methods such as mktemp(1), tempfile(1), and tempnam(3). The entire section is a mess. 150.101.52.48 (talk) 01:52, 22 July 2010 (UTC)Reply
I also think that this section should be removed. It doesn't have all that much to do with Maildir itself, only about some implementation details. Anyway, re above comment: I'm fully aware of different ways to create temporary files atomically. That's just largely irrelevant to the problem (it's about maildir base filename collisions, there can be multiple physical files with the same base filename). TimoSirainen (talk) 14:58, 25 July 2010 (UTC)Reply
I removed this section (since everyone seems to be in agreement including those that wrote most of it) and removed the quality warning flag as well. That doesn't fix the article, there are other statements of fact and implications to made about Maildir that aren't original research, as indicated in the earliest Talk comments. Dan Shearer (talk) 16:44, 16 April 2013 (UTC)Reply