موبائل ڈیوائس فائل سسٹم: یہ کیا ہے، ڈائریکٹری ساخت اور یہ کیسے کام کرتا ہے

موبائل ڈیوائس فائل سسٹم کیا ہے؟

فائل سسٹم آپریٹنگ سسٹم کا ایک سافٹ ویئر جزو ہے جو یہ منظم کرتا ہے کہ ڈیٹا فزیکل میڈیا پر کیسے لکھا، پڑھا اور منظم کیا جاتا ہے۔ موبائل ڈیوائسز پر، فائل سسٹم انتہائی اہم کام انجام دیتا ہے: فلیش میموری کی جگہ کا انتظام، اجازتوں کی بنیاد پر فائل تک رسائی کا کنٹرول، کریش کے بعد بحالی کے لیے تبدیلیوں کی جرنلنگ، اور NAND فلیش میموری کی خصوصیات کو مدنظر رکھتے ہوئے تحریر کی اصلاح۔

ڈیسک ٹاپ آپریٹنگ سسٹم کے برعکس، موبائل فائل سسٹم فلیش میموری کے محدود دوبارہ تحریر سائیکل کو مدنظر رکھ کر ڈیزائن کیے جاتے ہیں۔ NAND سیلز محدود تعداد میں مٹانے کے آپریشن برداشت کر سکتے ہیں — TLC اور MLC میموری کے لیے بالترتیب 3,000 سے 10,000 سائیکل۔ اسٹوریج کی عمر بڑھانے کے لیے، فائل سسٹم wear leveling میکانزم اور 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/، SQLite ڈیٹا بیس کے لیے databases/، SharedPreferences کے لیے shared_prefs/۔ اس ڈائریکٹری تک رسائی کی اجازتیں ایپلیکیشن انسٹال کرتے وقت مقرر کی جاتی ہیں اور روٹ رسائی کے بغیر تبدیل نہیں کی جا سکتیں۔ زیادہ تر جدید ڈیوائسز پر /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 (صارف ID) سے چلتی ہے۔ ایک ایپلیکیشن کے اپنے سینڈ باکس میں بنائی گئی تمام فائلیں اس 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() استعمال کریں، جو مختلف پلیٹ فارمز پر جدا کاروں کو صحیح طریقے سے ہینڈل کرتے ہیں۔