FTP

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2012. április 4., 13:31-kor történt szerkesztése után volt.

Írta: Billes Tibor, 2010. november

Az FTP, azaz File Transfer Protocol, egy alkalmazási rétegbeli protokoll, melyet fájlok átvitelére találtak ki. Egy korai változata már 1971-ben megjelent RFC 114 néven. A mostani szabványt az RFC 959 írja le, mely 1985-ben készült. Azóta számos kiegészítése született, részben kiegészítették, felülírták a korábbiakat.

Tartalomjegyzék

1 Története

A FTP nagyon régről indul, az első változata 1971 áprilisában jelent meg (ez még a TCP/IP előtt volt!), ez volt az RFC 114. Akkor a hálózat használatát két nagy kategóriába lehetett sorolni: direkt és indirekt. A direkt használat az volt, amikor az illető bejelentkezett a távoli számítógépre és egy terminálon keresztül úgy használta azt, mintha fizikailag is ott ülne előtte. Az indirekt pedig azt jelentette, hogy letöltök távolról egy erőforrást, a helyi gépen használom, majd ha végeztem, akkor visszatöltöm. Ez utóbbi felhasználást segítette az FTP.

Ez a legelső verzió definiálta az alapvető parancsokat és azok formátumát (ami egy "kicsit" eltér a maitól). Nem hiszem, hogy ezt a verziót emberi interakcióra tervezték, ugyanis a parancsokban NULL byte is szerepel, illetve néhány számot bináris formában kell megadni. A felhasználó azonosítása csupán név alapján történt, jelszavakat nem támogatott. Akkoriban nem volt ilyen jól menő üzletág az internetes csalás.

Az RFC 133 szigorítja az üzenetek kezelését, oly módon, hogy az előző verzióban a szerver nem minden esetben küldött választ a kliensnek. Ez ebben a verzióban kötelező. Mindig a szerveré az utolsó szó. Továbbá a hibakezeléssel foglalkozó részt is kiegészítették.

Az RFC 141 javaslatokat fogalmaz meg az FTP-ről, de nem tér ki nagyon a részletekre. Ne feledjük, hogy az RFC az Request For Comments. Ez itt egy komment. Viszont nem valósult meg belőle semmi.

Az RFC 172 az első teljesebb átalakítás, túl sok új funkciót nem ad hozzá, de az egész protokollt letisztázza, és egy külön adatátviteli protokollt (RFC 171) használ a konkrét adatcserére.

Az RFC 265 az RFC 172 kis kiegészítése, két új tranzakciótípust vezet be, illetve újabb hibakódokat. (Még mindig 1971-ben járunk, novembert írunk.)

Az RFC 354 (1972. július) egy viszonylag nagy módosítás volt, a protokoll ekkor nyerte el a mai formájának alapját. A parancsok immár tisztán ASCII karakterekből állnak, újsorral lezárva, illetve ebben a verzióban vezették be a háromjegyű, strukturált válaszkódokat. Másik fontos változtatás, hogy az adatkapcsolatnak nem kell állandóan nyitva lennie.

Ezután számos kiegészítés keletkezett, melyek új funkciókat definiáltak, kérdéseket vetettek fel bizonyos helyzetekről. Ezeknek az eredménye lett az RFC 542 1973 augusztusában, amely kísértetiesen hasonlít a ma is használt protokollra. Változások főleg az adatkapcsolat specifikációjában, a kérdés-válasz szekvenciákban voltak, és azokon a területeken, amik a TELNET protokolltól függnek. Viszont ez a verzió még mindig a TCP elődjét, az NCP-t preferálta.

Sok év szünet után 1980-ban jelent meg az RFC 765, amelyben a legszembetűnőbb változtatás az, hogy az egész protokollt TCP/IP alapra helyezi. Továbbá az elmúlt évek tapasztalatát, és a felvetődött kérdéseket, problémákat orvosolta.

1985 októberében keletkezett az RFC 959. Ez a legfrissebb olyan RFC, amelyik az FTP alapjait elejétől a végéig tartalmazza. Azóta számos RFC készült, amelyek kiegészítették, részben felülírták. Az RFC 959 sok újdonságot nem hozott az elődeihez képest, néhány opcionális parancs került bevezetésre, de mindez úgy, hogy a korábbi verzióval való kompatibilitása megmaradjon. Az azóta született kiegészítések közül a fontosabbak:

  • RFC 1579 : A tűzfalbarát FTP. Lényegében azt írja le, hogy állapotmentes csomagszűrővel nehéz jó tűzfalszabályt létrehozni a bejövő kapcsolatokhoz, ám a kimenő kapcsolatok kevesebb veszélyt jelentenek. Ezért használjuk a PASV parancsot az adatkapcsolat felépítésére, és hadd kelljen a szervernek portot nyitnia. Kevesebb szerver van, mint kliens, tehát ez így logikus.
  • RFC 1639 : FTP műveletek nagy címtartományban. A PORT és PASV parancsok egy 32 bites IP-címmel és egy 16 bites portszámmal dolgoznak, amik egyértelműen a TCP-re és IP-re tekintettel lévén született. Ez az RFC egy olyan általános megoldást ajánl, amivel ez a korlát feloldható, és tetszőleges hálózati és szállítási protokollokra alkalmazható.
  • RFC 2228 : FTP biztonsági kiegészítések. Ez a dokumentum új parancsokat vezet be, amelyekkel erős autentikáció, integritás védelem és bizalmasság garantálható mind a parancskapcsolatra, mind az adatkapcsolatra.
  • RFC 2389 : Feature egyeztetési mechanizmus az FTP-hez. A számos új kiegészítő bevezetésével szükségessé vált egy olyan módszer, amivel a kliens és a szerver megtudhatja egymásról, hogy melyik kiegészítőket támogatják. Ezt teszi lehetővé az a két új parancs, amit ez az RFC vezet be.
  • RFC 2428 : FTP kiegészítés IPv6-hoz és NAT-hoz. A PORT és PASV parancsok mellett vezet be új parancsokat, amelyek paramétere lehet IPv4-es és IPv6-os cím is. A NAT problémára is ajánl megoldást, bár nekem nem sikerült megérteni, hogy ez hogy működik.
  • RFC 2577 : FTP biztonsági megfontolások. Néhány problémát emel ki konkrétan. Az egyik, hogy a PORT paranccsal bárhova csatlakoztathatjuk a szervert. A javaslat ez ellen, hogy 0-1023 közötti portokra ne legyen hajlandó csatlakozni (így csökkentve a jól ismert szolgáltatások elleni támadásokat). Másik, hogy elvileg akárhányszor lehet próbálkozni egy felhasználó jelszavával (maximálni kéne a próbálkozások számát), a felhasználóneveket is védeni kéne, hogy sikertelen azonosítás esetén ne lehessen kikövetkeztetni, hogy a felhasználónév vagy a jelszó volt hibás.
  • RFC 2640 : Az FTP többnyelvűsítése. Az FTP karakterkészlete az ősidők óta 7 bites. Karakterkészletnek az UTF-8-at javasolja, valamint egy új parancsot amivel megállapodhatnak a használt nyelvben.
  • RFC 2773 : Titkosítás KEA és SKIPJACK használatával. A KEA egy kulcscserélő algoritmus, ami mind a két félnek biztosítja a hitelességét, a továbbiakban pedig a SKIPJACK biztosítja a titkosítást a parancs- és az adatkapcsolatra.
  • RFC 3659 : FTP kiegészítések. Egységes formátumot definiál a könyvtárlistázásnak, megteremti a lehetőségét a félbehagyott átvitel folytatására, és bevezet egy ún. triviális virtuális fájl tárat (Trivial Virtual File Store). Hogy ennek az utolsónak mi a célja, arra nem sikerült rájönnöm.
  • RFC 4217 : Az FTP biztosítása TLS-sel: Azt írja le, hogyan célszerű beleépíteni az FTP-szerverbe a TLS támogatást.
  • RFC 5797 : FTP parancs- és kiegészítéstár. Az IANA bevezet egy adatbázist, ahol nyilvántartják a rengeteg kiegészítőt és a parancsokat, hogy így csökkentsék a parancsütközések valószínűségét, és elkerüljék a félreértéseket.

Az RFC 1123 kakukktojás az előzőekhez képest, ez ugyanis globálisan minden internetes szolgáltatásra és alkalmazásokra vonatkozó követelményeket fogalmaz meg. A 4. rész foglalkozik az FTP-vel.

2 Működése

Az FTP kliens-szerver architektúrájú. A szerver általában a 21-es TCP porton fogadja a klienseket. Az itt felépülő kapcsolat lesz a "parancskapcsolat". Ezen a kapcsolaton csak a parancsok és szerver válaszai mennek, a konkrét adatok, a fájlok tartalma egy külön adatkapcsolaton fog továbbítódni. Az adatkapcsolat felépítéséről az Aktív vs. passzív mód fejezetben olvashatsz bővebben. Az adatkapcsolat csak egy adatfolyam erejéig szól, utána a kapcsolatot bezárják, és legközelebb újra ki kell építeni.

3 Parancsok

A teljesség igénye nélkül néhány gyakrabban előforduló parancs és jelentésük:

USER 
A (parancs)kapcsolat felépítése után a kliens ezzel mondja meg, hogy kicsoda is ő
PASS 
A felhasználónév megadása után ezzel lehet megadni a jelszót
LIST 
Könyvtárlistázás
DELE 
(Delete) Fájl törlése
RETR 
(Retrieve) A kliens szemszögéből egy fájl letöltése
STOR 
(Store) A kliens szemszögéből egy fájl feltöltése
APPE 
(Append) Egy feltöltés folytatása (hozzáfűzés fájlhoz)
REST 
(Restart) Egy letöltés folytatása
RNFR 
(Rename from) Az itt megadott fájlt átnevezi/áthelyezi az RNTO parancsban megadottra
RNTO 
(Rename to) A RNFR parancsban megadott fájlt átnevezi/áthelyezi az itt megadottra
MKD 
(Make directory) Könyvtár létrehozása
CWD 
(Change working directory) Könyvtárváltás
PWD 
(Print working directoy) Aktuális könyvtár lekérdezése
ABOR 
Az adatcsatornán éppen folyó fájlátvitel (aszinkron) megszakítása

4 Válaszkódok struktúrája

A HTTP-ben, POP3-ban használt válaszokhoz hasonlóan a szerver itt is egy 3 jegyből álló kódot küld válaszként, aminek az első számjegye meghatározza a művelet sikerességét.

1xx 
Előzetes pozitív válasz (elkezdte végrehajtani, eddig OK, de még nincs kész)
2xx 
Siker
3xx 
Közbenső pozitív válasz (a felhasználónak további parancsot kell kiadnia, hogy a műveletet el tudja kezdeni a szerver, pl. RNFR és RNTO, vagy USER és PASS)
4xx 
Ideiglenes hiba, a felhasználó újrapróbálkozhat a kéréssel
5xx 
Permanens hiba, nem érdemes újrapróbálkozni ugyanezzel a kéréssel

5 Aktív vs. passzív mód

Az adatkapcsolat felépítése történhet aktív vagy passzív módon. Aktív módban a szerver az, aki "aktív", mert ő nyitja az adatcsatornát. Passzív módban a szerver csak ül és várja, hogy a kliens csatlakozzon hozzá. A kliens minden adatkapcsolat felépítése előtt küld a szervernek egy PORT vagy egy PASV parancsot, ami meghatározza, hogy az adatkapcsolat felépítése milyen módon fog történni. Ez egy adatkapcsolat erejéig szól, tehát egy parancskapcsolat során tetszőleges sorrendben, tetszőleges számban előfordulhat aktív és passzív kapcsolatfelépítés.

Az aktív kapcsolat felépítése esetén a kliens egy PORT parancsot küld, amelyben megad egy IP-címet és egy portszámot. A szerver a 20-as TCP portjáról ide fog csatlakozni, és ezen az adatkapcsolaton fogja elküldeni vagy fogadni az adatokat.

Passzív esetben a kliens egy PASV parancsot küld, amire a szerver válaszol egy IP-cím és portszám párossal, ahova a kliensnek kapcsolódnia kell. Ha ez megtörtént, akkor indulhat az adatátvitel.

Az IP-cím és portszám elküldése egy furcsa formában történik. Az IP-cím 4 bájtos, a portszám 2 bájtos. Ezt a 6 bájtot küldik el decimálisan, vesszővel elválasztva. Példa:

PORT 127,0,0,1,20,10

Az IP cím jól kiolvasható: 127.0.0.1. A portszám már kevésbé. A 20-as a portszám felső bájtja, a 10-es az alsó. Visszaalakítani a következő képlettel lehet: 256*20 + 10. C nyelven akár így is: 20 << 8 + 10. A fenti portszám az 5130 akar lenni. További példa a Minta-session fejezetben olvasható.

6 FXP

A protokoll nem szabja meg, hogy a PORT parancsban milyen IP-címet kell megadni; olyat írok oda, ami nekem jól esik. Ezt kihasználva egymásnak lehet ereszteni két FTP-szervert úgy, hogy az "A" gépnek PASV parancsot küldök, a "B" gépnek pedig egy PORT parancsban elküldöm az "A" által visszaadott IP-t és portszámot. Az ötlet az, hogy a felhasználónak kis sávszélessége van, a szervereknek meg nagy, így két szerver között átvihetek gyorsan egy fájlt anélkül, hogy az a felhasználón keresztülmenne (kikerültük a szűk keresztmetszetet).

7 Biztonság

Az FTP nem elég biztonságos. A felhasználók hitelesítése egy plaintext jelszó alapján történik, nem támogat titkosítást. Ezért szükségessé vált bevezetni olyan megoldásokat, amelyekkel ezek a gondok orvosolhatóak.

RFC 2577
Ez az RFC kiemel néhányat az FTP biztonsági hiányosságaiból (támadási lehetőségek). A hiányosságok némelyikének befoltozására egyszerű megoldásokat javasol, másokra csak felhívja a figyelmet.
RFC 2228
Ez a kiegészítés bevezet új, opcionális parancsokat (és a hozzájuk tartózó hibakódokat is), melyekkel a kliens megegyezhet a szerverrel egy biztonsági szintben/titkosítási módban. Lehetőség van a felhasználó biztonságos azonosítására és hitelesítésére (az eddigi plain text jelszó helyett), titkosított adat- és parancskapcsolatra. Ez a kiegészítés nem definiálja, hogy milyen titkosítási algoritmusok használhatóak, csak az egyeztetés módját adja meg.
RFC 4217
FTP with TLS, vagy ismertebb nevén FTPS. Ez az előző pontban leírt biztonsági kiegészítéseket használja fel, illetve azt mondja meg, hogy azokat hogyan kell implementálni a TLS támogatáshoz.
FTP over SSH
Ez nem az FTP kiterjesztése; a módszer lényege, hogy egy SSH-kapcsolaton keresztül visszük át a csomagjainkat (tunneling), így azok élvezik az SSH által nyújtott biztonságot. Ez a biztonság azonban csak a parancskapcsolatra érvényes, hiszen az adatkapcsolatot a PORT illetve PASV parancsokban meghatározottak szerint építik fel. Ha az adatkapcsolatot is szeretnénk keresztülvezetni az SSH-alagúton, akkor (a NAT-hoz hasonlóan) címfordításra lesz szükségünk.
Előnye, hogy UNIX rendszereken egyszerűen kiépíthető, de a kliens oldalán is szükséges egy SSH-kliens megléte, így nem használható olyan esetekben, amikor szeretnénk, hogy minél több felhasználó tudjon probléma nélkül csatlakozni hozzánk.
SFTP
Ennek még annyi köze sincs az FTP-hez, mint az előbb említett módszernek, leginkább nincs is köze hozzá, csak a tisztánlátás érdekében sorolom fel itt. Ez a módszer az SSH-kapcsolaton keresztüli fájlátvitellel foglalkozik. Nem ugyanaz, mint az előbb említett módszer, ott az SSH-t csak alagutazásra használtuk, de a szerveren szükség van egy FTP-szerverre. Itt a fájlátvitel az SSH-protokoll része, és mindössze egy SSH-szerver szükséges hozzá.

A biztonságnak azonban ára van: Ha NAT mögött van a szerver vagy a kliens, akkor a NAT feladata a protokoll üzeneteiben az IP-cím és portszám lecserélése olyanra, amit a helyi hálózaton kívülről is el lehet érni. A titkosított adatfolyamban azonban a NAT ezt nem tudja megtenni.

8 Defektek, hibák, hátrányok

  • A protokollt eredetileg interaktívra tervezték, azaz, hogy a felhasználó majd kézzel pötyögi be a parancsokat és olvassa a válaszokat. Ezért a szabvány nem specifikálja a könyvtárlisták formátumát. Olvasni mindenki tud, de egy programból feldolgozni elég nehézkes: van-e fájlméret-mező, van-e dátummező, milyen sorrendben jönnek...
  • Aktív módban a szervernek kapcsolódnia kell a kliensekhez. Erre - állapotmentes csomagszűrőben - nehéz jó tűzfalszabályt létrehozni.
  • A PORT és PASV parancsok tartalmaznak IP-címet. Helyi hálózaton lehet pl. 192.168.1.3 a címünk. Azonban, ha ezt küldjük el a másik félnek, az a saját helyi hálózatán levő 192.168.1.3-as című gépre fog gondolni, ami feltehetőleg nem az, amit eredetileg akartunk. Ezért ha bármelyik gép NAT mögött van, az átjárónak címfordítást kell végeznie. Ha viszont titkosított kapcsolaton megy az FTP, akkor ezt nem tudja megtenni az átjáró.
  • A PORT paranccsal lehet portszkennelni. Ha sikerült kapcsolódnia, akkor az adott port nyitva van, ha nem, akkor nincs. Védekezés: csak azt az IP-címet fogadja el PORT parancsban, amin éppen folyik a parancskapcsolat. Ezzel megöltük az FXP lehetőségét.
  • A PORT paranccsal lehet levelet küldeni. Feltöltünk a szerverre egy fájlt, ami egy levél küldéséhez szükséges SMTP-parancsokat tartalmazza. A PORT parancsban egy SMTP-szerver IP-címét adjuk meg, portszámnak pedig a 25-öst. Az SMTP-szerver fogadja a kapcsolatot, az FTP-szerver pedig elküldi neki a fájlt, azaz elküldi az SMTP-parancsokat. Védekezni FTP az oldalán az előző pontban leírtaknak megfelelően lehet.
  • A PASV parancs kiadása utána a szerver vár egy kapcsolatra. Ha az eredeti kliens helyett egy támadó csatlakozik oda hamarabb, akkor a támadó tölthet fel fájlt / fogadhatja a letölteni kívánt fájlt. Természetesen az eredeti felhasználó nevével és jogosultságaival. Ehhez vagy le kell hallgatnunk a parancskapcsolatot vagy kitartóan próbálkozni a szerver összes portján, előbb-utóbb majd csak összejön. Védekezés az előző pontban leírtakhoz hasonlóan: csak onnan fogadunk el kapcsolatot, ahova a parancskapcsolat is szól. Ez megint csak ellehetetleníti az FXP-t.

9 Minta-session

A mintában az "S:" kezdetű sorokat a szerver küldte a kliens felé, a "C:" kezdetűket pedig a kliens a szervernek.

S: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------     // \
S: 220-You are user number 1 of 5 allowed.                           // |
S: 220-Local time is now 08:02. Server port: 21.                     //  > Banner
S: 220-This is a private system - No anonymous login                 // |
S: 220 You will be disconnected after 10 minutes of inactivity.      // /
C: USER vki                                                          // - Felhasználónév
S: 331 User vki OK. Password required                                // - 3xx-es visszatérési kód,
                                                                     //   azaz vár még valamire a
                                                                     //   szerver: jelszóra
C: PASS jelszo                                                       //   A jelszó plain textben van.
S: 230-User vki has group access to:  users                          //
S: 230 OK. Current directory is /                                    //
C: PORT 127,0,0,1,10,10                                              // - PORT parancs > aktív mód,
                                                                     //   a szerver fog csatlakozni
S: 200 PORT command successful                                       //   a klienshez.
C: STOR FTP_test.txt                                                 // - Fájl feltöltése
S: 150 Connecting to port 2570                                       // - Létrejön az adatkapcsolat
S: 226-File successfully transferred                                 // - Átvitel sikeres volt
S: 226 9.134 seconds (measured here), 7.55 bytes per second          //
C: PASV                                                              // - PASV -> most passzív
                                                                     //   módban vagyunk
S: 227 Entering Passive Mode (127,0,0,1,175,57)                      // - A szerver megmodja hova
                                                                     //   csatlakozzon a kliens
C: LIST                                                              // - Könyvtárlistázás
S: 150 Accepted data connection                                      // - Létrejött az adatkapcsolat
S: 226-Options: -a -l                                                //
S: 226 3 matches total                                               //
C: PASV                                                              // - Ismét passzív mód
S: 227 Entering Passive Mode (127,0,0,1,20,4)                        //
C: RETR FTP_test.txt                                                 // - Fájl letöltése
S: 150 Accepted data connection                                      //
S: 226-File successfully transferred                                 //
S: 226 0.000 seconds (measured here), 1.07 Mbytes per second         //
C: RETR nonexistentfile                                              // - Nem létező fájl letöltése
S: 550 Can't open nonexistentfile: No such file or directory         // - 5xx-es hibakód
C: RNFR FTP_test.txt                                                 // - Átnevezés erről
S: 350 RNFR accepted - file exists, ready for destination            // - 3xx-es visszatérési
                                                                     //   kód: vár valamire
C: RNTO FTP_test2.txt                                                // - Erre
S: 250 File successfully renamed or moved                            // - Sikeres átnevezés
C: QUIT                                                              // - Kilépés
S: 221-Goodbye. You uploaded 1 and downloaded 1 kbytes.              // - Köszönj szépen :)
S: 221 Logout.                                                       //

A fenti sessionből nagyon is látszik, hogy ezt a protokollt tényleg emberi interakcióra tervezték. A szerver szinte mindig teljes mondattal válaszol, a végén elköszön tőlünk, olyan statisztikákat közöl, amit egy gépi kliens simán megmérne magának, de nyilván az embernek érdekes (milyen gyors volt a letöltés, session végén összesítés, hogy mennyi adatot küldtem/fogadtam.). Valójában a válaszok formái, a közölt statisztikák szerverprogramonként változhatnak, a háromjegyű visszatérési kódok viszont kötöttek.

10 A könyvtárlisták formátumáról

A könyvtárlisták formátuma nincs egészen megszabva; ami azt illeti, nem is akarták megszabni. Idézet az RFC 959-ből:

Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user.

drwxrws---    2 536      536            71 Sep 23  2008 RCS
-r--r--r--    1 536      536          1912 Aug 05  2007 README
-r--r--r--    1 536      536           578 Mar 18  2003 README_ABOUT_BZ2_FILES
drwxrwsr-x    7 536      536            93 Jul 22  2005 dist
-r--r--r--    1 536      536          2322 Sep 23  2008 index.html
drwxrwsr-x   12 536      536           150 Apr 21 20:40 linux
drwxr-x---    2 536      536             6 Oct 27  1998 lost+found
drwxrwsr-x    3 536      536            18 Sep 23  2008 media
drwxrwsr-x   20 536      536          4096 Jun 25 22:34 scm
drwxrwsr-x    3 536      536            59 Nov 05  2003 site
drwxrwsr-x   13 536      536           154 Aug 22  2009 software
drwxr-sr-x    3 536      536            22 Apr 30  2008 tools
drwx------    2 1002       users            4096 Oct  5 08:06 .
drwx------    2 1002       users            4096 Oct  5 08:06 ..
-rw-r--r--    1 1002       users              69 Oct  5 08:03 FTP_test2.txt

A fenti két minta között elsőre nem szembetűnő, de bosszantó eltérések vannak:

  • a fájl tulajdonosának és csoportjának megadása névvel vagy számmal történik? Vagy vegyesen?
  • a dátum
    • első mezője a hónap 3 betűs angol rövidítése (lexikografikus rendezést megöltük)
    • második mezője a nap sorszáma. De bevezető nullákkal vagy anélkül? (lexikografikus rendezést felnégyeltük)
    • harmadik mezője pedig vagy évszám vagy időpont. Akkor időpont, ha idén történt a módosítás. (lexikografikus rendezést elhamvasztottuk)
    • időzóna?
    • egyáltalán az ott a módosítási idő?
  • a mezőket egynél több whitespace karakter is határolhatja, azért, hogy szemmel ránézve szép oszlopos rendezettséget lássunk

Léteznek ennél extrémebb példák is.

A Zehon FTP nevű Java komponens feature-listájában külön fejezetet kapott a 8 féle támogatott listaformátum.

Ez a Chrome bugreport egy Chrome által nem értelmezhető formátumról számol be (azóta persze javították):

 .
 ..
 .welcome
 Readme.doc
 setupPatch.exe

A következő, egy darab könyvtárat a cdhnow.com FTP-szerverétől sikerült kapnom.

08-13-10  11:41PM       <DIR>          aspnet_client

Szóval vannak érdekes darabok :)

Személyes eszközök