A mobileszköz fájlrendszere: mi ez, könyvtárstruktúra és hogyan működik

Mi a mobileszköz fájlrendszere?

Fájlrendszer az operációs rendszer szoftverkomponense, amely kezeli, hogy az adatok hogyan íródnak, olvasódnak és szerveződnek a fizikai adathordozón. Mobileszközökön a fájlrendszer kritikusan fontos funkciókat lát el: a flash memória területének kezelése, fájlokhoz való hozzáférés ellenőrzése engedélyek alapján, változtatások naplózása a hibák utáni helyreállításhoz, és az írás optimalizálása a NAND flash memória jellemzőinek figyelembevételével.

Ellentétben az asztali operációs rendszerekkel, a mobil fájlrendszereket a flash memória korlátozott újraírási ciklusainak figyelembevételével tervezik. A NAND cellák korlátozott számú törlési műveletet viselnek el — 3 000-től 10 000 ciklusig a TLC, illetve MLC memória esetében. A tároló élettartamának meghosszabbításához a fájlrendszerek wear leveling (kopáskiegyenlítő) mechanizmusokat és TRIM parancsokat alkalmaznak. A Samsung által kifejezetten flash memóriához fejlesztett F2FS figyelembe veszi a NAND tömb geometriáját és úgy helyezi el az adatokat, hogy minimalizálja a töredezettséget és a blokktörlési műveletek számát.

A modern mobileszközök több fájlrendszer kombinációját használják. A belső memória (/data partíció) Androidon EXT4 vagy F2FS, iOS-en APFS formátumú. Az SD kártyák hagyományosan exFAT-ot használnak a 4 GB-nál nagyobb fájlok támogatásához vagy FAT32-t a maximális kompatibilitásért. A /system partíció Androidon gyakran csak olvashatóként van csatolva, és EXT4 vagy EROFS (Enhanced Read-Only File System) — a Huawei által a rendszerpartíció méretének csökkentésére kifejlesztett tömörített fájlrendszer — használ.

Könyvtárstruktúra Androidon

Könyvtárhierarchia Android a Linux-struktúrán alapul, a gyökérrel a / mappában. Minden partíciónak saját fájlrendszere, hozzáférési jogai és rendeltetése van. Egy alkalmazás csak korlátozott számú könyvtárhoz férhet hozzá — a többi root jogokkal védett.

/data partíció és az alkalmazások sandbox-ja

A /data partíció a fő partíció a felhasználói adatok, telepített alkalmazások és beállításaik tárolására. Minden alkalmazás saját könyvtárat kap a /data/data/<package_name>/ útvonalon. Ezen könyvtáron belül a rendszer automatikusan alkönyvtárakat hoz létre: files/ az alkalmazás fájljaihoz, cache/ az ideiglenes fájlokhoz, databases/ az SQLite adatbázisokhoz, shared_prefs/ a SharedPreferences számára. A könyvtárhoz való hozzáférési jogok az alkalmazás telepítésekor kerülnek beállításra, és root hozzáférés nélkül nem módosíthatók. A /data partíció a legtöbb modern eszközön F2FS formátumú, ami akár 40%-kal magasabb véletlen írási sebességet biztosít az EXT4-hez képest.

/system partíció és rendszerkomponensek

A /system partíció tartalmazza az operációs rendszert, a rendszeralkalmazásokat és könyvtárakat. Ez a partíció csak olvashatóként van csatolva, hogy megakadályozza a rendszerfájlok véletlen vagy rosszindulatú módosítását. Az Android 10+ és Project Treble rendszerű eszközökön a /system partíció dinamikus, és OTA csomagokon keresztül frissíthető teljes újraflashelés nélkül. Az alkalmazások számára a /system partíció nem elérhető — egy írási kísérlet SecurityException kivételt vált ki. Az alkalmazások azonban olvashatnak bizonyos fájlokat a /system-ből, például rendszerbetűtípusokat és konfigurációs fájlokat, ha rendelkeznek a megfelelő engedélyekkel.

/sdcard csatolási pont

A /sdcard csatolási pont egy szimbolikus hivatkozás az emulált vagy fizikai külső tároló partíciójára. SD kártya nélküli eszközökön a /sdcard a /data-n belüli alpartícióra mutat, amely megosztott hozzáférésre van elkülönítve. Ez a partíció látható a felhasználó számára, amikor az eszköz MTP protokollon keresztül csatlakozik a számítógéphez. Az alkalmazások a /sdcard-hoz a READ_EXTERNAL_STORAGE és WRITE_EXTERNAL_STORAGE engedélyeken keresztül férnek hozzá, Android 10-től kezdve pedig a Scoped Storage-on keresztül a MediaStore API használatával. A /sdcard mérete általában az eszköz flash memóriája teljes térfogatának 60–80%-a, a többi a /data partíció számára van fenntartva.

Könyvtárstruktúra iOS-en

iOS-en a fájlrendszer az alkalmazások Sandbox konténerein keresztül van szervezve. Minden alkalmazás egy elkülönített könyvtárat kap, amelyhez a hozzáférés az XNU kernel szintjén korlátozott. A felhasználói partíció az iOS 10.3-ban bevezetett APFS (Apple File System) fájlrendszert használja. Az APFS támogatja a pillanatképeket, a fájlklónozást és a fájlszintű titkosítást, ami optimálissá teszi mobileszközökhöz.

A Sandbox konténer szabványos könyvtárai

Az iOS Sandbox konténer négy fő könyvtárat tartalmaz: Documents, Library, tmp és SystemData. Minden könyvtárnak saját biztonsági mentési politikája, adatmegőrzési ideje és hozzáférési szintje van. A Documents automatikusan bekerül az iCloud és iTunes biztonsági mentésbe. A Library alkönyvtárakat tartalmaz: Caches (nem kerül biztonsági mentésre), Preferences (biztonsági mentésre kerül) és Application Support (biztonsági mentésre kerül). A tmp könyvtár ideiglenes fájlok számára készült — az iOS törölheti ezeket, ha kevés a hely, és nem kerül biztonsági mentésbe. A SystemData-t maga a rendszer használja, és az alkalmazás számára nem elérhető a szabványos API-kon keresztül.

let fm = FileManager.default

let documents = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let caches = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let appSupport = fm.urls(
    for: .applicationSupportDirectory,
    in: .userDomainMask
).first!

A Sandbox konténer minden könyvtárának saját védelmi osztálya (protection class) van. Az iOS négy osztályt támogat: Complete Protection (a fájl nem elérhető zárolt eszköz esetén), Protected Unless Open (a már megnyitott fájlok zároláskor is elérhetők), Protected Until First User Authentication (a fájlok az első feloldás után elérhetők) és No Protection (a fájlok mindig elérhetők az eszköz rendszerindítása után). Alapértelmezés szerint a Documents és Library összes fájlja a Complete Protection osztályt kapja, ami garantálja a felhasználói adatok maximális védelmét. Fájl létrehozásakor explicit módon megadható más védelmi osztály, ha egy háttéralkalmazásnak zárolt eszköz esetén is hozzá kell férnie az adatokhoz.

Fájlrendszer hozzáférési jogai és biztonsága

A fájlokhoz való hozzáférés kezelése a mobileszközökön kulcsfontosságú különbség az Android és iOS között. Az Android a klasszikus Linux hozzáférési jogi modellt (olvasás, írás, végrehajtás) használja az alkalmazások elkülönítésére szolgáló kiterjesztésekkel. Az iOS szigorúbb Sandbox modellt alkalmaz, ahol minden alkalmazás egy elkülönített konténerben fut, és különleges mechanizmusok nélkül nem fér hozzá más alkalmazások fájljaihoz.

Engedélyek Androidon

Androidon minden alkalmazás külön UID-vel (User ID) indul. Az alkalmazás által a sandbox-ában létrehozott összes fájl ehhez az UID-hez tartozik, és nem látható más alkalmazások számára. A megosztott könyvtárakhoz (külső tároló) való hozzáféréshez az alkalmazásnak kérnie kell a READ_EXTERNAL_STORAGE és WRITE_EXTERNAL_STORAGE engedélyeket. Android 11-től kezdve az engedélyeket futásidőben kell kérni, és a targetSdkVersion 30+ alkalmazásnak más alkalmazások fájljaihoz való hozzáféréshez SAF-et kell használnia. Az engedélymodell megsértése SecurityException kivételt eredményez, amelyet a szabványos try-catch blokk kezel. A Google Play automatikusan ellenőrzi az alkalmazás megfelelését az engedélypolitikának a közzététel előtt.

if (ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.READ_EXTERNAL_STORAGE
) != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE),
        REQUEST_CODE
    )
}

Sandbox iOS-en és Keychain

iOS Sandbox az XNU kernel szintjén van implementálva, és nem engedi az alkalmazásnak, hogy elhagyja a konténerét. Még ha az alkalmazás hozzá is fér egy külső fájl URI-jához a Document Picker-en keresztül, az operációs rendszer egy ideiglenes másolatot hoz létre az alkalmazás konténerében, ahelyett hogy közvetlen hozzáférést biztosítana az eredetihez. A fájlok alkalmazások közötti megosztásához az iOS a Share Sheet és UIActivityViewController mechanizmusokat használja, amelyek átmásolják a fájlt az egyik alkalmazás konténeréből a másikéba. A hitelesítő adatok (tokenek, jelszavak, kulcsok) biztonságos tárolásához az iOS Keychain-t biztosít — egy titkosított tárhelyet, amely a kernel szintjén elérhető a rendszer számára. A Keychain nem része a Sandbox konténernek, és egy külön securityd démon kezeli, ami további védelmi réteget biztosít még az alkalmazás kompromittálódása esetén is.

A fájlrendszerek jellemzői: EXT4, APFS, F2FS

A fájlrendszer kiválasztása közvetlenül befolyásolja az adattárolás teljesítményét és megbízhatóságát. Minden fájlrendszernek saját architektúrája, optimalizálásai és korlátai vannak. A fejlesztő számára hasznos megérteni ezeket a különbségeket, hogy előre jelezze az alkalmazás viselkedését különböző eszközökön.

• EXT4 — szabványos Linux fájlrendszer naplózással, 16 TB-os fájlok és 1 EB-os kötetek támogatásával. Androidon főként az F2FS bevezetése előtt használták. A naplónak köszönhetően megbízhatóságot nyújt, de a véletlen írási sebességben elmarad az F2FS-től az inódok és blokkbitmapok minden műveletnél szükséges frissítése miatt
• F2FS — a Samsung által 2012-ben kifejezetten NAND flash memóriához fejlesztett fájlrendszer. Figyelembe veszi a flash tömb geometriáját, log-struktúrált architektúrát használ, és 25–40%-kal magasabb véletlen írási teljesítményt nyújt az EXT4-hez képest. Android 11-től a Google az F2FS-t ajánlja fő fájlrendszerként a /data partícióhoz
• APFS — az Apple fájlrendszere, 2017-ben bevezetve. Támogatja a pillanatképeket, fájlklónozást (copy-on-write), fájlszintű titkosítást és az adatok integritásának szigorú ellenőrzését ellenőrző összegeken keresztül. Az APFS SSD-kre van optimalizálva, és TRIM parancsokat használ a teljesítmény fenntartására a tároló teljes élettartama alatt
• exFAT — a Microsoft fájlrendszere, SD kártyákon és USB meghajtókon használatos. Támogatja a 4 GB-nál nagyobb fájlokat és a 128 PB-ig terjedő köteteket. Nincs naplózása, ezért hirtelen áramkimaradás adatsérüléshez vezethet. Cserélhető adathordozókhoz ajánlott, de nem rendszerpartíciókhoz

Az alkalmazások fejlesztésekor vegye figyelembe, hogy a különböző fájlrendszerek eltérő fájlnév-hossz korlátozásokkal (255 bájt EXT4 és F2FS esetén, 255 Unicode karakter APFS esetén), maximális fájlmérettel és speciális karakterek támogatásával rendelkeznek. Például az APFS lehetővé teszi a Unicode karaktereket a fájlnevekben, beleértve az emodzsikat, míg az EXT4 ASCII-ra korlátozott. Ha az alkalmazás különböző nyelveken elnevezett fájlokat hoz létre, tesztelje a működést az összes céleszközön — az APFS-en helyesen létrehozott fájlnév az EXT4-en csonkolódhat.

Javaslatok a fájlrendszerrel való munkához

Megbízható munka a mobileszköz fájlrendszerével néhány kulcsszabály betartását igényli. Ezek a fejlesztők tipikus hibáinak elemzésén és a hivatalos dokumentáció ajánlásain alapulnak.

• Ne használjon keményre kódolt útvonalakat a könyvtárakhoz. Az útvonalakat mindig rendszer API-kon keresztül szerezze be: context.filesDir Androidon, NSSearchPathForDirectoriesInDomains iOS-en. A kemény útvonalak változnak az operációs rendszer verziói és eszközök között
• Kezelje a kivételeket a fájlműveleteknél: IOException, FileNotFoundException, SecurityException. iOS-en az összes FileManager művelet hibát dobhat — csomagolja őket do-catch-be. Androidon a külső tárolóval végzett műveletek a média hiánya miatt hibával végződhetnek
• Ellenőrizze a rendelkezésre álló helyet írás előtt. Használja a File.getUsableSpace()-et Androidon és a URLResourceValues.volumeAvailableCapacityKey-t iOS-en. Figyelmeztesse a felhasználót, ha nincs elég szabad hely
• Kerülje a nagy fájlok tárolását a biztonsági mentésbe kerülő könyvtárakban. iOS-en zárja ki a gyorsítótárat a biztonsági mentésből az isExcludedFromBackup segítségével. Androidon részesítse előnyben a cacheDir-t az ideiglenes fájlokhoz
• Tesztelje a viselkedést a tárhely megtelése és hirtelen áramkimaradás esetén. Használjon tranzakciós írást: írjon egy ideiglenes fájlba, majd atomi módon nevezze át

Fordítson különös figyelmet a platformok közötti különbségekre. A fájlok útvonalai Androidon perjellel épülnek fel (/data/data/.../files/), iOS-en — URL séma segítségével (file:///var/mobile/.../Documents/). Ha alkalmazása többplatformos keretrendszert (Flutter, React Native, Kotlin Multiplatform) használ, egységesítse a fájlműveleteket platformadaptereken keresztül. Például a Flutter biztosítja a path_provider csomagot, amely platformfüggő kód írása nélkül adja vissza a helyes útvonalat a Documents vagy filesDir mappához mindkét platformon. Soha ne fűzze össze az útvonalakat sztringműveletekkel — használja a File.join() vagy URL.appendingPathComponent() függvényeket, amelyek helyesen kezelik az elválasztókat a különböző platformokon.