Timo Kinnunen
Särkiniementie 16 A 41
70700 Kuopio
Finland

Klikkaa tästä palataksesi takaisin Timon Serverimaailma etusivulle - Click here to return back to the front page of Timos' Serverimaailma homesite

Klikkaa tästä palataksesi takaisin Timon suomenkielisten DOS ja OS/2-oppaiden valintasivulle - Click this link to Return back to The Page of Timo's Finnish DOS and OS/2 manuals

Klikkaa tästä palataksesi takaisin sivulle Tietoo - Click this link to Return back to the page of Information

Johdatus HPFS tiedostosysteemiin

Johdanto

Tässä oppaassa esittelen tiedostojärjestelmää, jonka Microsoft valmisti suurta IBM -yhtiötä varten. Tästä käytetty lyhenne HPFS viittaa englanninkieliseen ilmaisuun High Performance File System, ja sillä nimetään eräs tiedostojärjestelmä, jota OS/2 -käyttöjärjestelmä voi käyttää eräiden muiden tiedostojärjestelmien ohella, ja joka on teknisesti samankaltainen kuin Windows NT järjestelmän NTFS. Kyseessä on kummassakin tapauksessa tavallaan sellainen järjestelmä, jossa on tuki muille tiedostojärjestelmille. OS/2 Warp 3.0 järjestelmä tukee jo perusasennuksena DOS -ja Windows 95 -järjestelmien FAT -tiedostojärjestelmää, ja siihen voi helposti liittää DOS -emulaattorin, ja WIN-OS2 -tuen. Tällaisia tukiominaisuuksia voi laajentaa myös muiden tiedostojärjestelmien suuntaan, koska systeemiin kuuluu ns. "IFS" -järjestelmän (Installable File System) -tuki:

1. MacIntosh -HFS

MacIntosh - käyttöjärjestelmän hfs -tiedostojärjestelmän tuen asentamista varten on saatavissa arkisto HFS0101.ZIP, jonka sisältämillä välineillä voidaan käsitellä MacIntosh -alutettuja levykkeitä, ja CD ROM -levyjä. Arkistossa HFS001.ZIP taas on välineet, joilla voidaan sekä lukea - että kirjoittaa MacIntosh -levykkeille.

2. Windows NT - NTFS

Windows NT -käyttöjärjestelmän NTFS -tiedostojärjestelmän tuen asentamista varten on saatavissa arkisto NTFS_002.ZIP, jossa on ajuri, joka mahdollistaa NT -partitioiden näkemisen normaaleina levyasemina, ja tietenkin siten myös niiden käsittelyn. Itselläni ei ole tästä työvälineestä yhtään kokemuksia.

3. Linux - ext2fs

Linux -käyttöjärjestelmän ext2fs -tiedostojärjestelmän tuen asentamista varten on saatavissa arkisto EXT2_05B.ZIP, joka sopii taas Linux -partitioiden tutkimiseen.

4. Windows 95 -VFAT

Windows 95 -käyttöjärjestelmän vfat -tiedostojärjestelmien tuen asentamista varten on saatavissa arkisto VFAT_001.RAR. Tämän lisävarusteen käyttö on tarpeen esimerkiksi tapauksissa, joissa yritetään muuntaa 32-bittisiä Windows -ohjelmia OS/2 sovelluksiksi Win32-OS/2 -projektin valmistamalla kääntäjällä senjälkeen, kun sovellukset on asennettu ensin Windows -järjestelmään. Käytännössä tämä kaikki tarkoittaa sitä, että OS/2 järjestelmään voidaan liittää ajureita, jotka mahdollistavat muidenkin tiedostojärjestelmien käytön - eli kyse on "asennettavista tiedostojärjestelmistä" - mihin englanninkielinen ilmaus IFS (Istallable File System) -viittaa. Tätä varten järjestelmässä on FSD -ajuri, joka sisältää rakenteen, joka muistuttaa dynaamista kirjastoa, mutta sillä on yleensä SYS tai IFS -tarkenne. Tällaiseen viittaus löytyy CONFIG.SYS -tiedostosta. HPFS suunniteltiin nimenomaan OS/2 järjestelmää varten, ja siinä pienimmän varausyksikön koko on aina 512 tavua. Tämä merkistsee sitä, että jos työskennellään paljon pienikokoisten tiedostojen kanssa, on seurauksena taloudellisempi levytilan käyttö, ja parempien hakuoiminaisuuksien vuoksi myös nopeutta löytyy enemmän kuin FAT -tiedostojärjestelmässä.

Mistä tämän selvityksen tiedot ovat peräisin?

Tämän esitykseni pohjana on osittain Microsoftin lehdessään julkaisema englanninkielinen artikkeli, joka löytyi tekstimuodossa IBM Suomi -purkista vielä sen toimiessa. Tietoni perustuvat myös omiin kokemuksiini tällaisista tiedostojärjestelmistä. Näiden tietojeni perusteella HPFS tiedostojärjestelmästä on minulle muodostunut seuraavanlainen yleiskuva.

Millainen HPFS on?

HPFS -järjestelmän eräs olennainen lisäominaisuus verrattuna esimerkiksi FAT -tiedostojärjestelmään on tiedostoon ja hakemistoihin liitettävät laajennetut attribuutit (EAs = Extended Attributes), joilla voidaan mm. säädellä tiedostojen käyttöä, antaa erilaisia käyttöoikeuksia palvelinversiossa, ja linkittää tiedostoja erilaisiin käynnistäviin sovelluksiin, ja siten integroida järjestelmää kokonaisuudessaan. Kysessä on ns. "objekti-orientoitunut tiedostojärjestelmä". Suurissa koneissa tällaisia järjestelmiä on ollut käytössä jo kauemmin, ja samantapaisia ominaisuuksia sisältäen - kuten AIX ja VMS, ja niissä korostuneita ovat nimenomaan erilaiset tiedostojen ja hakemistojen suojaukset, ja käyttöoikeuksien anto. Tällaisia ominaisuuksia liittyy myös Linuxin tiedostojärjestelmään. Samoja turvaominaisuuksia liittyy myös HPFS järjestelmän LAN Manager -versioon, jossa nimenomaan suojausominaisuudet erottavat sen esimerkiksi OS/2 Warp 3.0 -järjestelmässä käytetystä tiedostojärjestelmän versiosta. HPFS järjestelmän LAN Manager -versio tukee nimittäin myös toista tiedostoihin lisättyjen tietojen luokkaa, jota kutsutaan nimellä Access Control Lists (ACLs). Niillä on samanlainen yleinen ilmentymä kuin edelläkuvatuilla laajennetuilla attribuuteilla, ja niitä myös käsitellään samalla tavalla, mutta niitä käytetään esimerkiksi käyttöoikeuksien, salasanojen, ja muun vastaavan informaation tallentamiseen, jotka ovat tärkeitä monikäyttäjäympäristössä.

HPFS levyaseman rakenne

HPFS partitiot ovat tyyppiä 7, ja niitä voi olla kiintolevyllä samanaikaisesti levyllä jo ennestään olevien FAT partitioiden rinnalla. Kuitenkaan DOS, joka on FAT -partitiossa typillinen käyttöjärjestelmä, ei kykene näkemään HPFS -partitiota muutoin kuin erityisten ajureiden avulla - ja silloinkin siihen liittyy tiettyjä riskejä. IBM -yhteensopivat HPFS -partitiot käyttävät sektorikokoa 512 bittiä, ja partitoiden suurin koko voi olla huikeat 2199 gigatavua. On kuitenkin eräitä tietoja, joiden mukaan OS/2 järjestelmän Chkdsk -ohjelma hidastuisi huomattavastikin suurilla partitioilla. Vertailun vuoksi voi todeta, että Windows NT käyttöjärjestelmänNTFS järjestelmässä suurin osiokoko on teoreettisesti huikeat 2048 gigatavua, mutta koska tässä järjestelmässä varausyksikön koko kasvaa FAT -järjestelmän tapaan levypartition koon kasvaessa, ei NTFS ei ole tässä mielessä parempi vaihtoehto. Vaikka ei olekaan olemassa mitään erityistä syytä miksei levykkeitä voitaisi alustaa HPFS -tiedostojärjestelmälle, Microsoft on jatkanut levykkeiden tiedostojärjestelmänä FAT -kokoonpanoa, ja Windows 95 järjestelmä on sille myös leimallisesti optimoitu. Uusi Windows 98 sisältää mahdollisuuden asentaa 32-bittisen FAT -tiedostojärjestelmän, josta seuraa samalla se, että voidaan käyttää suurempia levypartitoita kuin 2 gigatavua, ja säästä levytilan käytössä. Ongelmana on vain se, että muut käyttöjärjestelmät eivät ymmärrä VFAT32 -tiedostojärjestelmää. Jos käytössä on 16-bittinen FAT -tiedostojärjestelmä, voivat tätä "kanavaa" myöten sekä MS-DOS, Windows 95, sekä OS/2 liittyä toisiinsa, tai ainakin vaihtaa keskenään tietoja. Kaikki mainitut käyttöjärjestelmät nimittäin alustavat levykkeitä oletuksena FAT -tiedostojärjestelmälle. Windows 95 järjestelmän tukemat pitkä hakemisto- ja tiedostonimet eivät ole yhteensopivia OS/2 järjestelmän ja sen HPFS tiedostojärjestelmän tukemien pitkien tiedostonimien kanssa, koska edellisen formaatti ei ole suoraan yhteensopiva OS/2 järjestelmän käyttämän formaatin kanssa, jossa "lyhyt" tiedostonimi voi olla 15 merkkiä pitkä. On kuitenkin olemassa eräitä apuohjelmia, joiden avulla tiedostojen vaihto onnistuu tästä huolimatta. Tietenkin OS/2 -järjestelmässä voidaan toki antaa pidempiäkin kuin 15-merkin mittaisia nimiä tiedostoille, mutta tässä lyhyessä muodossa ne ovat tallennettuina HPFS tiedostojärjestelmän Fnodessa, ja voidaan nimenomaan tämän sisältämän information perusteella palauttaa takaisin. Kun Windows 95 järjestelmän alkuosaltaan samanlaisten pitkien hakemisto- ja tiedostonimien muodostamaa luetteloa tarkastellaan DOS -komentokehoitetilassa, katkeaa pitkä tiedostonimi jo kuudennen merkin kohdalla, jota seuraa välittömästi "~" -merkki, ja sitä jokin numero. Sellaiset tiedostonimet, joiden tarkenne on enemmän kuin kolme merkkiä, näkyvät juuri tässä muodossa, ja vaikka tiedoston tarkenteessa olisi enemmän kuin kolme merkkiä, ei niistä näy kuin kolme. Siten tällaisen "tilde" -merkin näkyminen tiedostonimissä merkitsee aina sitä, että informaatiota on tarjolla enemmänkin, mutta sitä ei vain voida nähdä DOS tilassa. On huomattava, että Windows 95 rekistereissä saattaa esiintyä näistä hakemisto- ja tiedostonimistä sekä lyhyitä -että pitkiä muotoja, ja siten käytäntö ei ole kovinkaan yhtenäinen. Kumpikin vaihtoehto toimii, ja joka tapauksessa tähän järjestelmään asennetut 16-bittiset sovellukset eivät voi nähdä tiedostoja muutoin kuin 8+3 -muodossa, ja tallentaa niitä sellaisina. HPFS partitiolla on joitakin kiinteitä rakenteita, kuten sektorit 0-15 (koko 8 -kilotavua), joka on nimeltään BootBlock, ja se sisältää 32-bittisen asemanimen, sekä levyn käynnistysohjelman. Tämä ohjelma on mutkikas, ja MS-DOS -standardin mukainen. Käynnistysohjelma voi käyttää HPFS -levyasemaa tavallaan rajoittuneessa muodossa lukeakseen käyttöjärjestelmätiedostoja. Eräällä tavoin Windows 95 järjestelmän käynnistymistapa on samantapainen, sillä järjestelmä käynnistyy ensin DOS -tilaan, ja vasta senjälkeen työpöydäksi. HPFS -tiedostojärjestelmässä sektorit 16 ja 17 ovat nimeltään SuperBlock ja SpareBlock. Näistä SuperBlock on ainoastaan levynhallintatyökalujen käytössä, ja se sisältää osoittimet vapaan tilan bittikartoille, huonojen blokkien luettelon, hakemistoblokin, sekä juurihakemiston. Se sisältää myös päiväyksen, jolloin asemaa on viimeksi tarkistettu. SuperBlock -lohkon korjaamiseen käytetään OS/2 järjestelmän komentoa CHKDSK/F. Jälkimmäinen SpareBlock sisältää useita flageja sekä osoittimia, ja sitä päivitetään kun järjestelmä käynnistetään. 16-bittisessä FAT -tiedostojärjestelmässä tätä osiota vastaa tilanvaraustaulu - eli FAT (File Allocation Table), joka sijaitsee heti käynnistyslohkon jälkeen. Loppuosa levyasemasta on HPFS -tiedostojärjestelmässä jaettu 8 megatavun osiin, ja jokaisella niistä on oma vapaan tilan bittikartta, jossa bitti edustaa jokaista sektoria. Bitti on arvoltaan 0, jos sektori on käytössä, ja 1, jos sektori on vapaa. Bittikartat on sijoitettu joko osan alkuun tai loppuun niin, että kaksi bittikarttaa ovat peräkkäin vaihtoehtoisten osien kanssa. Tästä syystä suurimman mahdollisen yhtenäisen tilan koko yhtä ainutta tiedostoa varten voi olla 16 megatavua. Tavallinen kotikäyttäjä tarvitsee tavattoman harvoin tällaisia levytiloja, mutta poikkeuksena voivat olla eräät levynpoltto-ohjelmien käyttämät välitallenteet kintolevylle ennen varsinaista polttoa, tai erittäin massiiviset kuvatiedostot, tai tietokannat. Yksi osista, joka sijaitsee levyn hakukeskuksen jommalla kummalla puolen, on nimeltään hakemistoblokkiosa, ja sitä käsitellään erityisellä tavalla. Tässä esiteltyjen osien koko voi olla jokin muukin kuin edellämainittu, mikä riippuu tietenkin tiedostojärjestelmän versiosta, mutta periaate niissä on suunilleen sama.

Tiedostot ja "EFFnodet"

Jokainen HPFS levyaseman tiedoston ja hakemiston toiminta perustuu fundamentaaliseen tiedostojärjestelmäobjektiin, jonka nimi on "Fnode". Termin "node" eräs synonyymi on "connection" tai "corvex shape", jotk jo ilmaisevat mistä tässä on kyse - eli eräänlaisesta laajennuksesta ja liittymästä, tai solmukohdasta. Jokainen "Fnode" varaa tilaa sektorin verran, ja sisältää kontrollin, ja käyttöhistorialliset tiedot, joita tiedostojärjestelmä käyttää sisäisesti. Siinä ovat myös eräät laajennetut attribuutit, ja saantikontrolliluettelot, sekä tiedot tiedoston pituudesta, sekä tiedostonimen tai hakemiston 15 ensimmäistä kirjainta, sekä varausrakenne. Jokainen "Fnode" sijaitsee fyysisesti aina mahdollisimman lähellä sitä hakemistoa tai tiedostoa, jota se edustaa. "Fnoden" varausrakenteella voi olla monelaisia muotoja, mikä riippuu tiedoston tai hakemiston koosta ja niiden jatkuvuuden asteesta. HPFS näkee tiedoston yhden tai useamman jatkuvan sektorin kokoelmana, jota on ajettu kerran, tai useammasti. Jokainen ajo ilmaistaan symbolisesti 32-bittisen aloitussektorinumeron, sekä 32-bittisen sektoripituuden sanaparina (ajopituuden (Runlenght) mukainen määritys). Sovellukset eivät kuitenkaan näitä näe, vaan tiedosto näkyy niiden kannalta katkeamattomana bittivirtana. Tästä syystä sovellukset eivät myöskään vaikuta suoraan tiedostojärjestelmän toimintaan. "Fnoden" sisältämä tila varausinformaation säilyttämiseen voi sisältää aina kahdeksan sektoreiden ajoa aina 16 -megatavuun asti kunkin kohdalla (tämä johtuu osan suurimmasta mahdollisesta koosta, sekä bittikartan sijoituksesta, eikä ole tiedostojärjestelmän sisäinen rajoitus). Tästä syystä pienet tiedostot, sekä hyvin yhtenäiset tiedostot voidaan kuvata täydellisesti "Fnoden" avulla. HPFS käyttää myös toisenlaista menetelmää kuvatakseen tiedostoja, jotka ovat liian suuria kuvattavaksi "Fnoden" avulla, tai ovat liian hajanaisia sen käsiteltäväksi, tai jotka sisältävät enemmän kuin kahdeksan ajoa. Edelkläkäsitelty "Fnode" -varausrakenne on pohjana B+ Tree -puuvaraussektoreille, jotka sisältävät varsinaiset osoittimet tiedostosektorien ajolle. Koska "Fnodessa" on tilaa 12 -elementille, ja jokainen varaussektori voi sisältää useita kontrollitietoja, kuten 40 osoitinta sektoriajoille - voi kaksitasoinen varaus B+ kuvata tiedoston 480:na sektoriajona (12*40), ja siten tiedoston teoreettinen maksimaalinen koko voi olla 7.68 gigatavua. Tosin 32-bittinen offset-parametri DosChgFilePtr -varten rajaa tiedostojen suurimmaksi mahdoliseksi kooksi 2 gigatavua. Kuitenkin jokainen sunnuntaikirjailija käsittää, että eihän kukaan tavallinen ihminen tällaisiten kanssa ole juurikaan tekemisissä. Siinä epätodennäköisessä tapauksessa, että kaksitasoinen B+ ei riittäisi kuvaamaan pahoin sirpaleista tiedostoa, tuo järjestelmä kuvaukseen mukaan lisää tasoja jos se on tarpeen. Varaussektorit välittävillä tasoilla voivat sisältää aina 60 sisäistä B+Tree -rakenne "Nodea", mikä tarkoittaa sitä, että rakenten kuvauskyky nousee täysin käsittämättömiin lukemiin. B+ Tree -rakenne voi nimittäin teoriassa kuvata 28,800 sektoriajoa Runlength -enkoodaus ja B+ -varaussektorien puut ovat eräs muistin tehokkaan käytön kannalta hyvä keino määritellä tiedoston koko ja sen sijainti, mutta niillä on myös muita merkittäviä etuja. Loogisen tiedoston offsetin kääntäminen sektorinumeroksi on äärimmäisen nopea tapahtuma, koska tiedostojärjestelmän tarvitsee vain ajo-osoitinluettelot tai B+ luettelot siihen saakka kunnes se löytää oikean jakson, ja senjälkeen järjestemä voi määrittää sektorin ajon aikana yksinkertaisella laskutoimituksella. Ajon aikainen enkoodaus tekee tiedoston laajentamisen myös triviaaliksi, jos uudet osiot seuraavat heti viimeisen sektorin jälkeen, koska järjestelmän tarvitsee vain lisätä viimeisen ajo-osoittimen kaksoisanan kokoa, ja puhdistaa sektorin bitti soveltuvassa vapaan tilan bittikartassa.

Hakemistojen kuvaus HPFS tiedostojärjestelmässä

Hakemistojen kuvaus perustuu tiedostojen tapaan Fnodes -systeemiin. SuperBlock sisältää viittauksen Fnodeen juurihakemistoa varten, mutta muiden hakemistojen Fnodet voidaan tavoittaa niiden "parent" -hakemistojen alihakemistojen kautta. Tästä syystä "parent" hakemistoilla on erityisen suuri merkitys myös työpöydän ohjelmaobjektien toiminnan kannalta. Kun hakemistojen määrä kasvaa, tapahtuvat lisäyksen kahden kilotavun blokkeina, jotka muodostuvat toisiaan välittömästi seuraavista neljästä sektorista. Tiedostojärjestelmä yrittää varata näitä hakemistoblokkeja hakemistovyöhykkeeltä, joka sijaitsee lähellä levyn keskustaa sijaitsevaa hakukeskusta. Kun hakemistovyöhyke on täynnä, varataan hakemistoille tilaa missä sitä vain on saatavissa. Jokainen kahden kilotavun blokki sisältää yhdestä useampaan hakemistonimeä, ja kukin hakemisto taas useita kenttiä - mukaan lukien päivämäärän -ja ajan, Fnode -osoittimen, käyttölaskurin (jota levyn ylläpito-ohjelmat käyttävät), hakemiston tai tiedoston koon, itse nimen, sekä B-puun osoittimen. Tällaisen järjestelyn etuna on se, että jokaisessa hakemistoa koskevassa kenttäkokonaisuudessa on aina myös vapaata tilaa, jota voivat käyttää tiedostojärjestelmien erityisversiot. Hakemistoblokissa olevien nimien määrä riippuu siitä, miten pitkiä ne ovat. Jos keskimääräinen tiedostonimen pituus on 1-3 -merkkiä, voi blokki sisältää 40 nimeä. Nimet on aakkostettu blokissa nimikenttien mukaan binaariseen aakkosjärjestykseen (ja itse nimetkin sattuvat asettumaan siten aakkosittain). Viimeinen nimi blokissa on niin sanottu "tyhmä" nimi, jonka tehtävänä on osoittaa blokin loppukohta. Kun jokin hakemisto kasvaa niin sureksi, ettei sen tietoja voida enää ilmaista yhden blokin avulla, kasvatetaan blokin kokoa kahden kilotavun lisäyksin, jotka on organisoitu seuraavasti:

B Puu
B Puut
B+ Puut

Kun jotakin nimeä etsitään, tiedostojärjestelmä selaa hakemistoblokkia kunnes se löytää vastaavuuden, tai nimen, joka on aakkosissa etsityn edellä. Jälkimmäisessä tapauksessa tiedostojärjestelmä purkaa B -Puun osoittimen. Jos osoitinta ei löydy, etsintä epäonnistuu; mussa tapauksessa etsintä siirtyy seuraavaan hakemistoblokkiin, ja etsintä jatkuu. Oletetaan, että blokkia kohti voi olla 40 -nimikettä. Tällöin kasitasoinen puu voi sisältää 1640 hakemistonimikettä, ja kolmitasoinen puu hämmästyttävät 65,640 -nimikettä. Toisin sanoen jokin erityinen tiedosto voi löytyä -tai tulla ilmoitetuksi "ei esiintyväksi" - tyypillisessä 65,640 -tiedoston hakemistossa kun levyä on luettu vain kolmen kertaa. Tietenkin tämä riippuu myös kiintolevyn Cachen sisällöstä, ja tiedoston nimen sijainnista hakemistoblokin B-puussa. Siten voi sanoa, että HPFS tiedostojärjestelmän eräs valtti on sen hakutoimintojen nopeudessa. Jos tätä verrataan FAT -järjestelmään, olisi siinä vastaava levyaktiviteettien määrä 4000 sektorin lukutapahtumaa, jotta voitaisiin konstruoida 65,640 tiedoston hakemistosta tiedosto, tai tunnistaa, ettei etsittyä tiedostoa ole olemassakaan. Tietenkin esimerkiksi suorittimen nopeus voi auttaa asiaa, mutta lukukertojen määrää se ei vähennä, eikä prosessin yksi-yhteen -periaatetta. Tiedoston luominen, ja uudelleennimeäminen, tai tiedoston tuhoaminen voi olla monien aktiviteettien seuraamusta, koska hakemistoblokkeja lisätään, tai niihin syötetään tietoa, tai nimikkeitä siirretään blokista toiseen - jotta puu pysyisi tasapainossa. Teoreettisesti tiedoston uudelleennimeäminen voisi B-puussa epäonnistua jos levytilaa ei ole riittävästi - vaikka tiedoston koko ei kasvaisikaan ollenkaan. Kuitenkin HPFS välttää tämäntapaisenkin tilanteen pitämällä yllä pientä joukkoa vapaita blokkeja, jotka ovat käytettävissä jos tilanne tulee eteen. Ne ovat Spare Block -tilassa.

Laajennetut tiedostoattribuutit (Extended Attributes)

Tiedostoattribuutit ovat käyttöjärjestelmän ylläpitämää informaatiota tiedostosta, jota ylläpidetään tiedoston varsinaisen säilytysalueen ulkopuolella. FAT -tiedostojärjestelmä ylläpitää muutamaa yksinkertaista attribuuttia (read only, system, hidden, ja archive), jotka tallennetaan bittilippuina tiedoston hakemistonimikkeeseen. Niitä voidaan muokata erityisillä järjestelmäkutsuilla - eli käytännössä Attrib -ohjelmalla, ja tavallisessa tiedostonkäsittelyssä niihin ei jurikaan kajota. Kuitenkin juuri tämä tekee FAT tiedostojärjestelmästä erityisen askeettisen, ja tietoturvasta ei juurikaan voi puhua, koska kuka tahansa osaa tällaiset suojaukset purkaa, ja niitä ei kontrolloida tietokoneen pääkäyttäjän toimesta. HPFS tukee näitä samoja attribuutteja historiallisesta syystä, mutta tukee näiden lisäksi myös uutta laajennettujen attribuuttien muotoja (Extended Attributes (EAs)). Jokainen EA on käsitteellisesti samanlainen ympäristömuuttujaan nähden, joka on muotoa:

name value

paitsi että arvo voi päättyä ASCIIZ -arvoon (null), tai binaariseen dataan. Jos sinulla on OS/2 1.2 järjestelmä, voidaan jo siinä jokaiseen tiedostoon tai hakemistoon liittää 64 kilotavua laajennettuja attribuutteja, ja uudemmissa versioissa arvo on tätä korkeampi. Laajennettujen attribuuttien tallennusmenetelmä voi vaihdella. Jos tietyn tiedoston EA on riittävän pieni, se tallennetaan suoraan Fnodeen. Jos taas laajennettujen attribuuttien koko on liian suuri tähän, ne tallennetaan Fnoden ulkopuolelle, ja tarkoitusta varten luodaan B+Tree -tilanvaraustaulu kuvaamaan niiden ajoa. Jos jokin laajennettu attribuutti kasvaa liian suuriksi tähän, ne siirretään B+Tree -rakenteen ulkopuolelle, ja niitä varten luodaan oma B+Tree. Tavallisen kotikäyttäjän kannattaa huomioida mahdolliset tiedostoihin liittyvät laajennetut attribuutit esimerkiksi niin, että aina kun purkaa ZIP -tiedostoja, tekee sen ohjelmalla, joka kykenee käsittelemään laajennettuja attribuutteja, ja purkamaan niitä jos sellaisia arkiston tiedostoihin on liitetty. Ytimen API funktiot "DosQFileInfo" ja "DosSetFileInfo" on laajennettu uudelle informaatiotasolle, ja ne mahdollistavat sovelluksille sen, että ne voivat käsitellä laajennettuja tiedostojen attribuutteja. Uusia funktioita "DosQPathInfo" ja "DosSetPathInfo" käytetään polkunimiin liitettyjen laajennettujen attribuuttien lukemiseen. Sovellus voi joko pyytää arvoa tietylle laajennetulle attribuutille, tai lukea (ja asettaa) kaikki hakemiston tai tiedoston laajennetut attribuutit kerralla. HPFS on siten eräs versio sellaisesta objekti-orientoituneesta järjestelmästä, jossa mitä tahansa tiedostoja koskevaa informaatiota voidaan tallentaa laajennettuina attribuutteina. Tällaisia ovat esimerkiksi sen sovelluksen nimi, joka tiedostoa käyttää, ja tiedostoon voi liittyä myös kuvake, joka karakterisoi ajettavaa ohjelmaa. Tällaisen kytkennän jälkeen jo pelkkä dokumenttitiedostokuvakkeen klikkaaminen työpöydästä voi käynnistää varsinaisen ohjelman, jolla tiedosto on luotu, tai joka sitä kykenee käsittelemään, tai on erikseen sellaiseksi määritelty. Ongelmia voi kuitenkin tulla esimerkiksi tapauksissa, joissa sovelluksen suorittama dokumentin tunnistus perustuu yksinomaan tiedoston tarkenteeseen. OS/2 järjestelmässä tyypillinen ongelmallinen tapaus on tiedostotarkenne "DOC", joka voi olla aivan tavallinen tekstitiedosto, mutta myös jollakin Word -ohjelman versiolla tuotettu dokumentti. Jos järjestelmässä on asennettuna WIN-OS2 -tuki, ja sovellukset WinWord 6.0a tai WordPerfect 6.0a for Windows, voivat kumpikin näistä tunnistaa oman oletusdokumenttinsa tällä tarkenteella. OS/2 järjestelmän kannalta nämä eivät kuitenkaan ole oletussovelluksia, jotka käynnistyvät kun dokumentin kuvaketta klikataan, vaan sellainen on E.EXE. Jos tällä pienellä sovelluksella avataan jokin tekstitiedosto - tai esimerkiksi teksitimuotoinen Autoexec.BAT -eräajo, muutetaan sitä, ja tallennetaan se muutettuna, saa tiedosto työpöydässä tietyn kuvakkeen, joka viittaa tähän mainittuun sovellukseen - eli sitä käsitellään jatkossakin E.EXE -ohjelmalla, jos tätä kuvaketta klikataan. Jos taas mainitua eräajoa päivitetään TEDIT.EXE -ohjelmalla, nähdään työpöydässä vain yleisempää muotoia oleva lipuke - koska tämä sovellus ei linkkiydy erityisesti tekstitiedostoihin. Ongelmat eivät oikeastaan aiheudu tästä nimenomaisesta mekanismista, vaan siitä, että DOC -tiedostot eivät ole samanlaisia. On aivan turhaa yrittää käsitellä Word -dokumenttia E.EXE -sovelluksessa, koska se formaatti ei ole puhtaasti tekstimuotoinen, ja Word -ohjelman kannalta taas kaikki DOC -tarkenteet viittaavat sen omaan dokumenttimuotoon. Koska tällaisia tapauksia on muitakin, kuten se, että useat kuvankäsittelyohjelmat käyttävät kuvatiedostoissaan PIC -tarkennetta, tai että kaikki BMP -tiedostot eivät samasta tarkenteestaan huolimatta ole formaatiltaan yhteensopivia, seuraa tarkenteisiin kytkeytyvästä tunnistuksesta seurata ongelmia. Esimerkiksi OS/2 järjestelmän BMP -bittikartat eivät ole Windows -järjestelmän BMP -bittikarttojen kanssa täsmälleen identtisiä, vaikka esimerkiksi Image Alchemy kykeneekin niitä käsittelemään ja muntamaan ongelmitta.