मोबाइल डिवाइस फ़ाइल सिस्टम: यह क्या है, निर्देशिका संरचना और यह कैसे काम करता है

मोबाइल डिवाइस फ़ाइल सिस्टम क्या है?

फ़ाइल सिस्टम ऑपरेटिंग सिस्टम का एक सॉफ़्टवेयर घटक है जो प्रबंधित करता है कि डेटा भौतिक मीडिया पर कैसे लिखा, पढ़ा और व्यवस्थित किया जाता है। मोबाइल उपकरणों पर, फ़ाइल सिस्टम महत्वपूर्ण कार्य करता है: फ्लैश मेमोरी स्थान का प्रबंधन, अनुमतियों के आधार पर फ़ाइल एक्सेस नियंत्रण, क्रैश के बाद रिकवरी के लिए परिवर्तनों की जर्नलिंग, और NAND फ्लैश मेमोरी की विशेषताओं को ध्यान में रखते हुए लेखन अनुकूलन।

डेस्कटॉप ऑपरेटिंग सिस्टम के विपरीत, मोबाइल फ़ाइल सिस्टम फ्लैश मेमोरी के सीमित रीराइट चक्रों को ध्यान में रखकर डिज़ाइन किए जाते हैं। NAND कोशिकाएँ सीमित संख्या में मिटाने के संचालन को सहन कर सकती हैं — TLC और MLC मेमोरी के लिए क्रमशः 3,000 से 10,000 चक्र। स्टोरेज की आयु बढ़ाने के लिए, फ़ाइल सिस्टम वियर लेवलिंग तंत्र और TRIM कमांड का उपयोग करते हैं। F2FS, जिसे Samsung द्वारा विशेष रूप से फ्लैश मेमोरी के लिए विकसित किया गया है, NAND ऐरे ज्यामिति को ध्यान में रखता है और डेटा को इस तरह रखता है कि विखंडन और ब्लॉक मिटाने के संचालन की संख्या कम से कम हो।

आधुनिक मोबाइल उपकरण कई फ़ाइल सिस्टमों के संयोजन का उपयोग करते हैं। आंतरिक मेमोरी (/data विभाजन) Android पर EXT4 या F2FS और iOS पर APFS के रूप में स्वरूपित होती है। SD कार्ड पारंपरिक रूप से 4 GB से बड़ी फ़ाइलों के लिए exFAT या अधिकतम संगतता के लिए FAT32 का उपयोग करते हैं। Android पर /system विभाजन अक्सर केवल-पढ़ने के लिए माउंट किया जाता है और EXT4 या EROFS (Enhanced Read-Only File System) का उपयोग करता है — Huawei द्वारा सिस्टम विभाजन का आकार कम करने के लिए विकसित एक संपीड़ित फ़ाइल सिस्टम।

Android पर निर्देशिका संरचना

Android की निर्देशिका पदानुक्रम / में रूट के साथ Linux संरचना पर आधारित है। प्रत्येक विभाजन का अपना फ़ाइल सिस्टम, एक्सेस अनुमतियाँ और उद्देश्य होता है। कोई एप्लिकेशन केवल निर्देशिकाओं के एक सीमित सेट तक ही पहुँच सकता है — बाकी रूट अनुमतियों द्वारा संरक्षित हैं।

/data विभाजन और ऐप सैंडबॉक्स

/data विभाजन उपयोगकर्ता डेटा, स्थापित एप्लिकेशन और उनकी सेटिंग्स को संग्रहीत करने के लिए मुख्य विभाजन है। प्रत्येक एप्लिकेशन को /data/data/<package_name>/ पथ पर अपनी निर्देशिका मिलती है। इस निर्देशिका के अंदर, सिस्टम स्वचालित रूप से उपनिर्देशिकाएँ बनाता है: files/ एप्लिकेशन फ़ाइलों के लिए, cache/ अस्थायी फ़ाइलों के लिए, databases/ SQLite डेटाबेस के लिए, shared_prefs/ SharedPreferences के लिए। इस निर्देशिका तक पहुँच अनुमतियाँ एप्लिकेशन स्थापित करते समय निर्धारित की जाती हैं और रूट एक्सेस के बिना बदली नहीं जा सकतीं। अधिकांश आधुनिक उपकरणों पर /data विभाजन F2FS के रूप में स्वरूपित होता है, जो EXT4 की तुलना में 40% तक उच्च यादृच्छिक लेखन गति प्रदान करता है।

/system विभाजन और सिस्टम घटक

/system विभाजन में ऑपरेटिंग सिस्टम, सिस्टम एप्लिकेशन और लाइब्रेरीज़ होती हैं। यह विभाजन सिस्टम फ़ाइलों के आकस्मिक या दुर्भावनापूर्ण संशोधन को रोकने के लिए केवल-पढ़ने के लिए माउंट किया जाता है। Android 10+ और Project Treble वाले उपकरणों पर, /system विभाजन गतिशील है और पूर्ण रिफ्लैश की आवश्यकता के बिना OTA पैकेज के माध्यम से अपडेट किया जा सकता है। एप्लिकेशन के लिए, /system विभाजन दुर्गम है — लिखने का प्रयास SecurityException फेंकेगा। हालाँकि, यदि उनके पास उपयुक्त अनुमतियाँ हैं तो एप्लिकेशन /system से कुछ फ़ाइलें पढ़ सकते हैं, जैसे सिस्टम फ़ॉन्ट और कॉन्फ़िगरेशन फ़ाइलें।

/sdcard माउंट पॉइंट

/sdcard माउंट पॉइंट एम्युलेटेड या भौतिक बाहरी स्टोरेज विभाजन का एक प्रतीकात्मक लिंक है। SD कार्ड के बिना उपकरणों पर, /sdcard साझा पहुँच के लिए निर्दिष्ट /data के भीतर एक उपविभाजन को इंगित करता है। जब उपकरण MTP प्रोटोकॉल के माध्यम से कंप्यूटर से कनेक्ट होता है तो यह विभाजन उपयोगकर्ता को दिखाई देता है। एप्लिकेशन READ_EXTERNAL_STORAGE और WRITE_EXTERNAL_STORAGE अनुमतियों के माध्यम से /sdcard तक पहुँचते हैं, और Android 10 से शुरू — MediaStore API का उपयोग करके Scoped Storage के माध्यम से। /sdcard का आकार आमतौर पर कुल फ्लैश मेमोरी का 60–80% होता है, और शेष /data विभाजन के लिए आरक्षित होता है।

iOS पर निर्देशिका संरचना

iOS पर, फ़ाइल सिस्टम एप्लिकेशन के लिए सैंडबॉक्स कंटेनरों के माध्यम से व्यवस्थित होता है। प्रत्येक एप्लिकेशन को एक पृथक निर्देशिका मिलती है जिसकी पहुँच XNU कर्नेल स्तर पर प्रतिबंधित होती है। उपयोगकर्ता विभाजन APFS (Apple File System) का उपयोग करता है, जिसे iOS 10.3 में पेश किया गया था। APFS स्नैपशॉट, फ़ाइल क्लोनिंग और फ़ाइल-स्तरीय एन्क्रिप्शन का समर्थन करता है, जो इसे मोबाइल उपकरणों के लिए इष्टतम बनाता है।

मानक सैंडबॉक्स कंटेनर निर्देशिकाएँ

iOS सैंडबॉक्स कंटेनर में चार मुख्य निर्देशिकाएँ शामिल हैं: Documents, Library, tmp और SystemData। प्रत्येक निर्देशिका की अपनी बैकअप नीति, डेटा प्रतिधारण अवधि और पहुँच स्तर होता है। Documents स्वचालित रूप से iCloud और iTunes बैकअप में शामिल होता है। Library में उपनिर्देशिकाएँ Caches (बैकअप नहीं), Preferences (बैकअप) और Application Support (बैकअप) होती हैं। tmp निर्देशिका अस्थायी फ़ाइलों के लिए है जिन्हें iOS स्टोरेज कम होने पर हटा सकता है — यह बैकअप में शामिल नहीं होती। SystemData का उपयोग सिस्टम द्वारा ही किया जाता है और मानक API के माध्यम से एप्लिकेशन के लिए दुर्गम है।

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!

प्रत्येक सैंडबॉक्स कंटेनर निर्देशिका की अपनी सुरक्षा वर्ग होती है। iOS चार वर्गों का समर्थन करता है: पूर्ण सुरक्षा (डिवाइस लॉक होने पर फ़ाइल दुर्गम है), संरक्षित जब तक खुला न हो (पहले से खुली फ़ाइलें लॉक होने पर सुलभ हैं), पहली उपयोगकर्ता प्रमाणीकरण तक संरक्षित (पहले अनलॉक के बाद फ़ाइलें सुलभ हैं), और कोई सुरक्षा नहीं (डिवाइस बूट के बाद फ़ाइलें हमेशा सुलभ हैं)। डिफ़ॉल्ट रूप से, Documents और Library में सभी फ़ाइलों को पूर्ण सुरक्षा वर्ग मिलता है, जो उपयोगकर्ता डेटा की अधिकतम सुरक्षा सुनिश्चित करता है। फ़ाइल बनाते समय, आप स्पष्ट रूप से एक अलग सुरक्षा वर्ग निर्दिष्ट कर सकते हैं यदि किसी पृष्ठभूमि एप्लिकेशन को डिवाइस लॉक होने पर डेटा तक पहुँचने की आवश्यकता हो।

फ़ाइल सिस्टम एक्सेस अनुमतियाँ और सुरक्षा

मोबाइल उपकरणों पर फ़ाइलों तक पहुँच नियंत्रण Android और iOS के बीच एक महत्वपूर्ण अंतर है। Android एप्लिकेशन अलगाव के लिए विस्तार के साथ क्लासिक Linux अनुमति मॉडल (पढ़ना, लिखना, निष्पादित करना) का उपयोग करता है। iOS अधिक सख्त सैंडबॉक्स मॉडल का उपयोग करता है, जहाँ प्रत्येक एप्लिकेशन एक पृथक कंटेनर में चलता है और विशेष तंत्र के बिना अन्य एप्लिकेशन की फ़ाइलों तक पहुँच नहीं रखता है।

Android पर अनुमतियाँ

Android पर, प्रत्येक एप्लिकेशन एक अलग UID (उपयोगकर्ता आईडी) के तहत चलता है। किसी एप्लिकेशन द्वारा उसके सैंडबॉक्स में बनाई गई सभी फ़ाइलें इस UID की होती हैं और अन्य एप्लिकेशन के लिए अदृश्य होती हैं। साझा निर्देशिकाओं (बाहरी स्टोरेज) तक पहुँचने के लिए, एप्लिकेशन को READ_EXTERNAL_STORAGE और WRITE_EXTERNAL_STORAGE अनुमतियों का अनुरोध करना होगा। Android 11 से शुरू, रनटाइम पर अनुमतियों का अनुरोध किया जाना चाहिए, और targetSdkVersion 30+ वाले एप्लिकेशन को अन्य एप्लिकेशन की फ़ाइलों तक पहुँचने के लिए SAF का उपयोग करना चाहिए। अनुमति मॉडल का उल्लंघन SecurityException का कारण बनता है, जिसे मानक try-catch ब्लॉक द्वारा संभाला जाता है। Google Play प्रकाशन से पहले अनुमति नीति के साथ एप्लिकेशन के अनुपालन की स्वचालित रूप से जाँच करता है।

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

iOS सैंडबॉक्स और कीचेन

iOS सैंडबॉक्स XNU कर्नेल स्तर पर लागू किया गया है और एप्लिकेशन को अपने कंटेनर से बाहर निकलने की अनुमति नहीं देता है। भले ही एप्लिकेशन को Document Picker के माध्यम से बाहरी फ़ाइल URI तक पहुँच मिल जाए, ऑपरेटिंग सिस्टम मूल तक सीधी पहुँच प्रदान करने के बजाय एप्लिकेशन के कंटेनर में एक अस्थायी प्रतिलिपि बनाता है। एप्लिकेशन के बीच फ़ाइल साझा करने के लिए, iOS Share Sheet और UIActivityViewController तंत्र का उपयोग करता है, जो एक एप्लिकेशन के कंटेनर से दूसरे में फ़ाइल कॉपी करते हैं। क्रेडेंशियल (टोकन, पासवर्ड, कुंजियाँ) के सुरक्षित भंडारण के लिए, iOS कीचेन प्रदान करता है — कर्नेल स्तर पर सिस्टम के लिए सुलभ एक एन्क्रिप्टेड स्टोरेज। कीचेन सैंडबॉक्स कंटेनर का हिस्सा नहीं है और एक अलग securityd डेमॉन द्वारा प्रबंधित किया जाता है, जो एप्लिकेशन से समझौता होने की स्थिति में भी सुरक्षा की एक अतिरिक्त परत प्रदान करता है।

फ़ाइल सिस्टम की विशेषताएँ: EXT4, APFS, F2FS

फ़ाइल सिस्टम का चुनाव सीधे स्टोरेज प्रदर्शन और विश्वसनीयता को प्रभावित करता है। प्रत्येक फ़ाइल सिस्टम की अपनी आर्किटेक्चर, अनुकूलन और सीमाएँ होती हैं। डेवलपर के लिए इन अंतरों को समझना उपयोगी है ताकि विभिन्न उपकरणों पर एप्लिकेशन के व्यवहार का पूर्वानुमान लगाया जा सके।

• EXT4 — जर्नलिंग के साथ एक मानक Linux फ़ाइल सिस्टम, जो 16 TB तक की फ़ाइलों और 1 EB तक के वॉल्यूम का समर्थन करता है। F2FS अपनाने से पहले Android पर प्राथमिक फ़ाइल सिस्टम के रूप में उपयोग किया जाता है। जर्नलिंग के माध्यम से विश्वसनीयता प्रदान करता है, लेकिन प्रत्येक ऑपरेशन पर इनोड और ब्लॉक बिटमैप को अपडेट करने की आवश्यकता के कारण यादृच्छिक लेखन गति में F2FS से कमतर है
• F2FS — Samsung द्वारा 2012 में विशेष रूप से NAND फ्लैश मेमोरी के लिए विकसित एक फ़ाइल सिस्टम। फ्लैश ऐरे ज्यामिति को ध्यान में रखता है, लॉग-संरचित आर्किटेक्चर का उपयोग करता है, और EXT4 की तुलना में 25–40% अधिक यादृच्छिक लेखन प्रदर्शन प्रदान करता है। Android 11 से शुरू, Google /data विभाजन के लिए प्राथमिक फ़ाइल सिस्टम के रूप में F2FS की सिफ़ारिश करता है
• APFS — Apple का फ़ाइल सिस्टम जो 2017 में पेश किया गया। स्नैपशॉट, फ़ाइल क्लोनिंग (कॉपी-ऑन-राइट), फ़ाइल-स्तरीय एन्क्रिप्शन और चेकसम के माध्यम से सख्त डेटा अखंडता नियंत्रण का समर्थन करता है। APFS SSD के लिए अनुकूलित है और स्टोरेज जीवनकाल में प्रदर्शन बनाए रखने के लिए TRIM कमांड का उपयोग करता है
• exFAT — Microsoft का फ़ाइल सिस्टम जो SD कार्ड और USB ड्राइव पर उपयोग किया जाता है। 4 GB से बड़ी फ़ाइलों और 128 PB तक के वॉल्यूम का समर्थन करता है। इसमें जर्नलिंग नहीं है, इसलिए अचानक बिजली की हानि से डेटा भ्रष्ट हो सकता है। हटाने योग्य मीडिया के लिए अनुशंसित, लेकिन सिस्टम विभाजन के लिए नहीं

एप्लिकेशन विकसित करते समय, ध्यान रखें कि विभिन्न फ़ाइल सिस्टमों की फ़ाइल नाम लंबाई सीमाएँ (EXT4 और F2FS के लिए 255 बाइट, APFS के लिए 255 Unicode वर्ण), अधिकतम फ़ाइल आकार और विशेष वर्ण समर्थन अलग-अलग होते हैं। उदाहरण के लिए, APFS फ़ाइल नामों में Unicode वर्णों की अनुमति देता है, जिसमें इमोजी शामिल हैं, जबकि EXT4 ASCII तक सीमित है। यदि आपका एप्लिकेशन विभिन्न भाषाओं में नामों वाली फ़ाइलें बनाता है, तो सभी लक्ष्य उपकरणों पर परीक्षण करें — APFS पर सही ढंग से बनाया गया फ़ाइल नाम EXT4 पर छोटा हो सकता है।

फ़ाइल सिस्टम के साथ काम करने की सिफ़ारिशें

मोबाइल डिवाइस फ़ाइल सिस्टम के साथ विश्वसनीय काम के लिए कई प्रमुख नियमों का पालन करना आवश्यक है। ये डेवलपर्स की विशिष्ट गलतियों और आधिकारिक दस्तावेज़ीकरण की सिफ़ारिशों के विश्लेषण पर आधारित हैं।

• निर्देशिकाओं के लिए हार्डकोडेड पथ का उपयोग न करें। हमेशा सिस्टम API के माध्यम से पथ प्राप्त करें: Android पर context.filesDir, iOS पर NSSearchPathForDirectoriesInDomains। हार्डकोडेड पथ OS संस्करणों और उपकरणों के बीच बदलते हैं
• फ़ाइल संचालन के अपवादों को संभालें: IOException, FileNotFoundException, SecurityException। iOS पर, सभी FileManager संचालन त्रुटियाँ फेंक सकते हैं — उन्हें do-catch में लपेटें। Android पर, बाहरी स्टोरेज के साथ संचालन मीडिया की अनुपलब्धता के कारण विफल हो सकते हैं
• लिखने से पहले उपलब्ध स्थान की जाँच करें। Android पर File.getUsableSpace() और iOS पर URLResourceValues.volumeAvailableCapacityKey का उपयोग करें। यदि खाली स्थान अपर्याप्त है तो उपयोगकर्ता को चेतावनी दें
• बड़ी फ़ाइलों को उन निर्देशिकाओं में संग्रहीत करने से बचें जो बैकअप में शामिल होती हैं। iOS पर, isExcludedFromBackup के माध्यम से कैश को बैकअप से बाहर करें। Android पर, अस्थायी फ़ाइलों के लिए cacheDir पसंद करें
• स्टोरेज भर जाने और अचानक बिजली की हानि पर व्यवहार का परीक्षण करें। लेन-देन संबंधी लेखन का उपयोग करें: एक अस्थायी फ़ाइल में लिखें, फिर परमाणु रूप से नाम बदलें

क्रॉस-प्लेटफ़ॉर्म अंतरों पर विशेष ध्यान दें। Android पर फ़ाइल पथ फ़ॉरवर्ड स्लैश (/data/data/.../files/) का उपयोग करते हैं, iOS पर — URL योजना (file:///var/mobile/.../Documents/)। यदि आपका एप्लिकेशन क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क (Flutter, React Native, Kotlin Multiplatform) का उपयोग करता है, तो प्लेटफ़ॉर्म एडॉप्टर के माध्यम से फ़ाइल संचालन को एकीकृत करें। उदाहरण के लिए, Flutter path_provider पैकेज प्रदान करता है, जो प्लेटफ़ॉर्म-विशिष्ट कोड लिखे बिना दोनों प्लेटफ़ॉर्म पर Documents या filesDir का सही पथ लौटाता है। पथों को स्ट्रिंग संचालन से कभी संयोजित न करें — File.join() या URL.appendingPathComponent() का उपयोग करें, जो विभिन्न प्लेटफ़ॉर्म पर विभाजकों को सही ढंग से संभालते हैं।