| Maildir | |
|---|---|
| Típusú | E-mail archívum |
| Fejlesztő | Daniel J. Bernstein |
| Első kiadás | 2000 [1] |
A Maildir egy elterjedt e- mail tárolási formátum , amely nem igényel kizárólagos fájlrögzítést, hogy biztosítsa a postafiók integritását az üzenetek olvasásakor, hozzáadásakor vagy módosításakor. Minden üzenet külön fájlban van tárolva, egyedi névvel, és minden mappa egy . A fájlok hozzáadása, áthelyezése és törlése során a fájlok zárolását a helyi fájlrendszer kezeli . Minden változtatás atomi fájlműveletekkel történik, így semmiképpen sem szükséges kizárólagos fájlrögzítés.
A Maildir könyvtárnakMaildir (gyakran nevezik ) általában három alkönyvtára van: tmp, newés cur.
Az eredeti Maildir formátumspecifikációt Daniel Bernstein írta( Daniel J. Bernstein ), a qmail , a djbdns és más programok szerzője [2] . Bár az eredeti specifikációt a szerző kifejezetten a qmail programjához írta, az meglehetősen általános jellegű, így sok programban megvalósítható.
Sam Varshavchik, a Courier Mail Server és más programok szerzője megírta a Maildir formátum kiterjesztését [3] Maildir++ néven , hogy támogassa az almappákat és a levelezési kvótákat. A Maildir++ könyvtárak ponttal (".") kezdődő alkönyvtárakat tartalmaznak, amelyek egyben Maildir++ mappák is. Ez a kiterjesztés ebben a tekintetben sérti a Maildir specifikációt, amely kimerítő listát ad a Maildir lehetséges tartalmáról, de ez egy kompatibilis eltérés, és a Maildirt támogató egyéb szoftverek a Maildir++-t is támogatják.
Amikor egy üzenetet kézbesítenek, az egy alkönyvtárban lévő fájlba kerül tmp(például a postfix SMTP-kiszolgáló által ) . A fájlnév az aktuális időből, a gazdagép nevéből, a fájlt létrehozó folyamat azonosítójából és néhány véletlen számból alakul ki - így garantált a fájlnevek egyedisége.
A teljes üzenet fájlba írása után általában létrejön egy merev hivatkozás a könyvtárban lévő fájlhoz, newés az aktuális hivatkozás tmpeltávolításra kerül, de egyes megvalósításokban egyszerűen rendszerhívást használnak rename()– mindezt azért, hogy semmilyen más folyamat ne tudja addig olvassa el az üzenet tartalmát , amíg teljesen meg nem íródott, mivel a MUA -k soha nem néznek bele tmp.
Amikor a levelezőkliens üzeneteket talál a könyvtárban new, áthelyezi őket a (z) -ba cur(a használatával rename(), mivel ebben az esetben a merev hivatkozások használata duplikált üzenetekhez vezethet), és a fájlok elolvasása előtt információs utótagokat fűz a nevükhöz. Az információs utótag kettőspontból (a fájlnév egyedi részének az aktuális információtól való elválasztására), a „2” számból, egy vesszőből és különböző zászlókból áll . A „2” szám durván szólva az információ tizedesvessző utáni változatát jelöli. A „2” az egyetlen jelenleg hivatalosan meghatározott verzió. Az „1” a kísérleti verzióra utal. Csak feltételezhetjük, hogy ezt a verziószámot használták a Maildir formátum fejlesztése során. A specifikáció jelzőket határoz meg, amelyek jelzik, hogy egy üzenetet elolvastak-e, töröltek-e és így tovább, a következő szavak első (nagybetűivel): Elfogadva, Válaszolva, Látva, Kukába helyezve, Piszkozat és Megjelölve [2] . A Dovecot kisbetűket (kisbetűket) használ, hogy megfeleljen a 26 IMAP kulcsszónak [4] , amelyek tartalmazhatnak szabványos kulcsszavakat, például $ MDNSent és felhasználó által definiált jelzőket is.
Daniel J. Bernstein úgy tervezte a Maildir-t, hogy több folyamat biztonságosan írhasson párhuzamosan, kifejezett zárolás nélkül, és még NFS használata esetén is. A gyakorlatban ez elég jól működik, de furcsaságokhoz vezethet. A könyvtárstruktúra olvasása közben readdir()előfordulhat, hogy az első és az utolsó rendszerhívás között átnevezett fájlok nem jelennek meg a fájllistában. Ez elhiteti az olvasóval, hogy az üzenetet törölték, holott valójában csak a zászlói változtak. Amikor a folyamat újra elolvassa az üzenetek listáját, hirtelen újra megjelenik a "törölt" üzenet. Az ilyen jellegű problémák kiküszöbölésére egyes levelezőprogramok saját zárakat vezetnek be a Maildir tetején. A Dovecot például saját, nem szabványos zárrendszerét használja a Maildirrel együtt.
A fájlrendszer implicit zárolásokat használ a könyvtárak frissítésekor. A nem fürtözött fájlrendszerek általában csak egy kernel szálnak engedik meg a végrehajtást egy adott időpontban, hogy frissítsék a könyvtárban lévő adatokat, így a rendszerhívás rename()biztosítja a szükséges zárolást. A Maildir nem zármentes rendszer, csak kifejezetten zárolásmentes. Sok kis és közepes méretű levelezőrendszer esetében ez még NFS-en is megfelelően méreteződik, de amikor a rendszer nagy lesz és sok egyidejű kézbesítést kezel, akkor sok könyvtár tartalmának egyidejű folyamatos változtatása folyamatosan érvényteleníti a gyorsítótár adatait (gyorsítótár érvénytelenítése). különböző NFS-kliensek, ezért újra kell futtatni a távoli eljáráshívásokat (RPC) a READDIR , ami nem skálázódik jól. Ezenkívül sok fájlrendszer korlátozza a könyvtáronkénti fájlok számát.
A Maildir tehát szenved az "egy levél, egy fájl" elvre épülő összes levéltároló rendszer örökölt méretezési korlátaitól.
A Maildir szabvány módosítás nélkül nem implementálható olyan rendszereken, amelyek nem támogatják a kettőspontot a fájlnevekben. Ide tartozik a Microsoft Windows és néhány Novell Storage Services konfiguráció is .
Az ilyen rendszereken futó programok használhatnak alternatív határolót (például ";" vagy "-"), és a használatához gyakran elegendő egy egyszerű javítással javítani a programot [5] , amennyiben ingyenes és nyílt forráskódú szoftverek . aggódik .
Mivel jelenleg nincs megállapodás arról, hogy melyik karaktert használjuk az alternatív határolóként, az ilyen rendszereken a Maildirt támogató különböző programok közötti együttműködési problémák léphetnek fel. De nem minden Maildirrel dolgozó programnak kell tudnia, hogy melyik határolót használja, mivel nem minden programnak kell tudnia olvasni vagy módosítani az üzenetjelzőket ("olvasott", "válaszolt" stb.). Azok a programok, amelyek csak a leveleket a Maildir-be kézbesítik, vagy a régi üzeneteket csak a dátum alapján archiválják, nem jelenthetnek problémát a használt határolótól függetlenül. Ha csak egy levelezőkliensnek kell elolvasnia és módosítania az üzenetjelzőket , és csak egy ilyen klienst használ, akkor nem lesz interakciós probléma a nem szabványos elválasztó használatakor.
A Maildirrel használható programok száma valójában sokkal nagyobb, tekintettel ezeknek a programoknak egymásra való interakciójára és a hálózati hozzáférési protokollok szerepére.
Például: