মোবাইল ডিভাইসের ফাইল সিস্টেম: এটি কী, ডিরেক্টরি কাঠামো এবং এটি কীভাবে কাজ করে

মোবাইল ডিভাইস ফাইল সিস্টেম কী?

ফাইল সিস্টেম হল অপারেটিং সিস্টেমের একটি সফ্টওয়্যার উপাদান যা পরিচালনা করে যে কীভাবে ডেটা ফিজিক্যাল মিডিয়ায় লেখা, পড়া এবং সংগঠিত হয়। মোবাইল ডিভাইসে, ফাইল সিস্টেম গুরুত্বপূর্ণ কার্য সম্পাদন করে: ফ্ল্যাশ মেমোরি স্থান ব্যবস্থাপনা, অনুমতির ভিত্তিতে ফাইল অ্যাক্সেস নিয়ন্ত্রণ, ক্র্যাশের পরে পুনরুদ্ধারের জন্য পরিবর্তনের জার্নালিং এবং 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() ব্যবহার করুন, যা বিভিন্ন প্ল্যাটফর্মে বিভাজকগুলি সঠিকভাবে পরিচালনা করে।