Re: Windows and Maildir

From: Sam (sam_at_email-scan.com)
Date: 07/14/04 

Date: Wed, 14 Jul 2004 17:50:27 -0500

Jonathan de Boyne Pollard writes:

> 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.

If you modify or replace the message status flags with something else,
you're no longer talking about maildir-maildirs. It's now something else.

> (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.

Only if those entities are not prepared to handle this eventuality.

> 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.

Is that why Linux+Samba spanks NT's monkey on the same hardware?

> 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.

It's more than just the linear directory. Take FFS with a directory
containing ten thousand files, then take NT with the same. No comparison
whatsoever. And there won't be much of a difference between FAT and NTFS.

> (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.

FAT: two decades' worth of revisions, and two decades worth of
backwards-compatibility crap. End result: a turd inside a turd inside a
turd to the n'th generation.

NTFS: one massive hairball. Its primary purpose is to raise the
interoperability bar to prevent access to the filesystem from non-Microsoft
technologies. Unnecessarily complicated, overengineered turkey.

In both cases you have massive amounts of bloat to cut through, before you
get to the files themselves.

Unix/Linux filesystems, on the other hand, are models of simplicity. I'll
take a filesystem benchmark of Linux ext3 against NT or XP, on the same
hardware, any time.

> 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.

There are “filesystem format” problems, and there are “filesystem format”
problems caused by decades' worth of backward-compatibility hacks (MICROS~1
anyone?) and artificially-overengineered bloat.

> 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.

“A little work” versus a plain, garden-variety, system call. Multiply by a
few hundred thousand, and you'll get the answer of why Samba is a better SMB
server than NT/XP itself.

Relevant Pages

  • Re: Cross Platform Directory Access
    ... >>to those partitions ... Prior to Windows NT, DOS and Windows used variants of the FAT ... From Windows NT onwards MS introduced the NTFS ... filesystem which supports better security and numerous other desirable ...
    (comp.unix.admin)
  • Re: OT: More OS questions
    ... I've always had more success recovering data from a FAT ... one than an NTFS. ... and just a floppy disk to boot from, ... as easily mountable from another Windows, Windows boot CD, or a Linux ...
    (uk.games.video.misc)
  • Re: unrecoverable problems
    ... if he has file allocation problems with the NTFS volume ... and uses Partition Magic to change to FAT 32 he will probably trash all data ... > will be run the next time your restart windows. ...
    (microsoft.public.windowsxp.newusers)
  • Re: NTFS drive thinks it is FAT
    ... Windows NT4&2000 MCSE ... Microsoft Enterprise Support ... XP found the drive identified it as FAT and said that it was ... > this drive can be called NTFS rather than FAT without a format? ...
    (microsoft.public.windows.file_system)
  • Re: FAT and NTFS
    ... NTFS vs. FAT: ... MS-MVP Windows Shell/User ... >> FAT is frankly only good for linux access. ...
    (microsoft.public.windowsxp.general)