Re: Windows and Maildir
From: Jonathan de Boyne Pollard (J.deBoynePollard_at_Tesco.NET)
Date: 07/14/04
- Next message: Paul: "growing and shrinking a partition"
- Previous message: Alessandro Costa: "Send String of char to another application"
- Next in thread: Sam: "Re: Windows and Maildir"
- Reply: Sam: "Re: Windows and Maildir"
- Reply: Neil Woods: "Re: Windows and Maildir"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 14 Jul 2004 16:44:22 GMT
I> Are there email clients like Eudora, Thunderbird, etc on
I> Windows that will read and store mail in a maildir-like
I> format (without the ":")?
S> Nope.
Several Unix MUAs have Maildir capability. Several of those have been
"ported" to Win32. I wouldn't be surprised if there were Win32 tools that
were capable of at least "maildir-like" functionality.
I> Surely that colon is not essential to its basic functionality.
S> Yes it is;
No, it isn't. The point of the colon is to allow for the storage of message
status information outside of the actual file contents. Maildir stores this
in the message filename itself. Unix has no further mechanisms available.
Other operating systems *have*, however. OS/2 Warp has extended attributes
(which seem tailor made for the sort of things that go into the "info" part of
a message filename). Windows NT with NTFS has both file streams and extended
attributes. (The fact that as a message changes status its filename changes
does cause and has caused difficulties with parallel uses of Maildirs by
multiple entities. It's interesting to note that using something like
extended attributes to store message status flags wouldn't cause the same
difficulties.)
S> With an average-sized mailbox containing thousands of messages,
S> it means that you will have thousands of small files lying around.
S> Windows fares very poorly with handling directories with large
S> numbers of files.
False. Several filesystem formats, such as FAT, fare very poorly with
handling large directories. But "FAT" is (obviously) not synonymous with
"Windows", and furthermore there are filesystem formats available for Windows
NT whose performance with large directories is better than that of FAT.
Indeed, one only has to realise that the BSD Unix FFS format has the *exact
same problem* with large directories, because like FAT it too stores
directories as simple linear lists, to realise that this is *not* a Windows
problem.
(Failing to realise that poor choice of filesystem format will affect Unix
softwares too, because the problem is in the filesystem format and not in the
operating system, is a common mistake made by mail administrators on Unix
systems, incidentally. Many seem to make the same mistake as here of thinking
that such things are "Windows problems" that couldn't possibly apply to Unix.
The effect of choice of filesystem format on the performance of the mail queue
is discussed in the literature on "qmail", though, even if not in the
literature on most other Unix MTSes.)
S> Linux, and Unix, handles directories containing large number
S> of files much better than Windows.
False. As explained above. Poor handling for large directories is just as
much a Linux and a Unix problem as it is a Windows problem, because it is a
*filesystem format* problem.
S> Additionally, maildirs use temporary hard links. There's no
S> such thing as a hard link, in Windows.
Win32 doesn't have a notion of hard links. NTFS does have hard links,
however. It is possible for a Windows NT program to use hard links on Windows
NT, albeit that such a program will not run on DOS-Windows.
S> Finally, modern implementations of maildirs require the
S> filesystem to implement the notion of a device/inode pair.
Delivery identifiers are required to be _unique_. They aren't required to
employ device/inode pairs in order to be so. (Indeed, the Maildir
specification itself points out that device numbers aren't even generally
useful in this context, let alone required.)
It would be interesting to determine whether using GUIDs would meet the
uniqueness requirements.
S> Windows has no such thing.
S> Quoting MSDN: "The inode, and therefore st_ino, has no
S> meaning in the FAT, HPFS, or NTFS file systems."
MSDN is, as is all too often the case, oversimplified to the point of being
wrong. NTFS has an inode analogue, the file's index in the MFT. With a
little work, it is possible to retrieve a volume-wide unique identifier for a
file on NTFS in a Windows NT program.
- Next message: Paul: "growing and shrinking a partition"
- Previous message: Alessandro Costa: "Send String of char to another application"
- Next in thread: Sam: "Re: Windows and Maildir"
- Reply: Sam: "Re: Windows and Maildir"
- Reply: Neil Woods: "Re: Windows and Maildir"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
