ফাইল I/O ও filesystem — ডেটাকে প্রোগ্রামের পরেও বাঁচিয়ে রাখা

১ · প্রোগ্রাম থামলে মেমরি শূন্য — ফাইল কেন লাগে

এই কোর্সে এ পর্যন্ত আপনার প্রতিটি প্রোগ্রামের একটি অদ্ভুত স্বভাব ছিল: সব ভুলে যায়। একটি std::vector-এ সারাদিনের বিক্রির হিসাব রাখলেন, প্রোগ্রাম বন্ধ করলেন — পরের বার চালালে vector আবার খালি। কারণ ভ্যারিয়েবল থাকে RAM-এ, আর প্রোগ্রাম শেষ হলে অপারেটিং সিস্টেম সেই মেমরি ফেরত নিয়ে অন্য কাজে দেয়। বিদ্যুৎ চলে গেলে তো কথাই নেই — RAM-এর সব তথ্য মুছে যায়।

শেষ কথাটিই এই পর্বের সবচেয়ে গভীর ধারণা। অপারেটিং সিস্টেমের চোখে একটি ফাইল শুধু একটি নাম আর তার পেছনে একটি বাইটের সারি — ০ থেকে ২৫৫ মানের একের পর এক সংখ্যা। “এটা একটি লেখা”, “এটা একটি ছবি”, “এখানে কমা দিয়ে আলাদা করা হিসাব” — এসব অর্থ ফাইলের ভেতরে লেখা থাকে না। অর্থ দেয় যে প্রোগ্রাম পড়ছে, একটি চুক্তি মেনে। সেই চুক্তির নাম file format. একই বাইটগুলো তিনভাবে পড়া যায়:

এই পর্বে আমরা চারটি বাস্তব কাজ ধরে এগোব: একটি দোকানের দিনের বিক্রির খাতা CSV-তে সেভ ও লোড করা, একটি লগ ফাইলে প্রতিটি ঘটনা যোগ করা, একটি ফোল্ডারের সব .txt ফাইল আকারসহ তালিকা করা, আর একটি config ফাইল পড়া। প্রতিটির পেছনে একই প্রশ্ন থাকবে: কী ভুল হতে পারে, আর ভুল হলে ডেটা বাঁচবে তো?

২ · ফাইলও একটি stream — ofstream, ifstream আর open mode

পর্ব ৭-এ দেখেছেন, std::cin আর std::cout হলো stream — বাইটের একটি প্রবাহ, যার একদিকে আপনার প্রোগ্রাম আর অন্যদিকে কিবোর্ড বা স্ক্রিন। C++-এর নকশার সুন্দর দিক হলো, অন্যদিকে স্ক্রিনের বদলে একটি ফাইল বসালেও আপনার কোড প্রায় একই থাকে। header <fstream>-এ তিনটি টাইপ:

ফাইল কীভাবে খোলা হবে, তা ঠিক করে open mode — std::ios-এর কয়েকটি flag, যেগুলো | দিয়ে জোড়া যায়:

• std::ios::in — পড়ার জন্য। std::ios::out — লেখার জন্য; একা দিলে পুরোনো লেখা মুছে যায়।
• std::ios::trunc — খোলার সময়েই ফাইল খালি করা (out-এর সাথে নিজে থেকেই হয়)।
• std::ios::app — append: প্রতিটি লেখা যায় ফাইলের শেষে, পুরোনো লেখা অক্ষত। লগ ফাইলের জন্য ঠিক এটাই চাই।
• std::ios::binary — বাইট যেমন আছে তেমন; newline-এর কোনো রূপান্তর নয় (অংশ ৫-এ বিস্তারিত)।
• std::ios::ate — খুলেই শেষে চলে যাওয়া; আর C++23 থেকে std::ios::noreplace — ফাইল আগে থেকে থাকলে খোলাই ব্যর্থ, যাতে ভুল করে কারও ফাইল মুছে না যায়।

একটি লগ ফাইলে প্রতিটি বিক্রির ঘটনা যোগ করার স্বাভাবিক রূপ এমন:

#include <fstream>
#include <print>
#include <string_view>

bool log_event(std::string_view msg) {
    std::ofstream log{"shop.log", std::ios::app};   // না থাকলে তৈরি, থাকলে শেষে যোগ
    if (!log) return false;                          // খোলা গেল কি না
    std::println(log, "{}", msg);                     // C++23: সরাসরি ফাইলে print
    return static_cast<bool>(log);                   // লেখাও সফল হলো কি না
}   // এখানে log ধ্বংস — destructor নিজেই flush করে ফাইল বন্ধ করে

তিনটি জিনিস খেয়াল করুন। প্রথমত, C++23 থেকে std::print আর std::println সরাসরি একটি std::ostream-এ (header <ostream>) বা C-এর FILE*-এ (header <print>) লিখতে পারে — ফরম্যাটের নিয়ম পর্ব ৭-এর মতোই। পুরোনো log << msg << '\n';-ও চলে। দ্বিতীয়ত, কোথাও close() নেই। std::ofstream একটি RAII টাইপ (পর্ব ১৭): constructor ফাইল খোলে, destructor buffer-এর বাকি লেখা পাঠিয়ে ফাইল বন্ধ করে — ফাংশন স্বাভাবিকভাবে শেষ হোক, আগে return হোক, বা exception ছুটুক। তৃতীয়ত, std::endl নেই। প্রতিটি endl একটি flush ঘটায়, আর হাজার লাইনের ফাইলে হাজারবার flush মানে অকারণে ধীর প্রোগ্রাম।

লেখা আসলে কখন ডিস্কে পৌঁছায়

std::println(log, ...) শেষ হওয়ার মানে কিন্তু এই নয় যে লেখাটি ডিস্কে বসে গেছে। মাঝে দুটি অপেক্ষার ঘর আছে — stream-এর নিজের buffer, আর অপারেটিং সিস্টেমের page cache. প্রতিটি ছোট লেখার জন্য ডিস্কে যাওয়া খুব ধীর, তাই সবাই জমিয়ে একসাথে পাঠায়। একটি লাইনের পুরো যাত্রা ধাপে ধাপে দেখুন:

int total = 435;
// প্রোগ্রাম এখন বন্ধ হলে: 435 হারিয়ে গেল

std::println(out, "total,{}", total);
// "total,435\n" আছে ofstream-এর buffer-এ
// ডিস্কের ফাইল এখনো খালি হতে পারে
// এখন crash হলে: লেখাটি হারাবে

out.flush();      // বা } — RAII destructor
// বাইটগুলো এখন OS-এর মেমরিতে
// প্রোগ্রাম crash হলেও টিকে থাকবে
// কিন্তু বিদ্যুৎ গেলে: না-ও থাকতে পারে

// কয়েক সেকেন্ডের মধ্যে OS ডিস্কে পাঠায়
// এখনই নিশ্চিত চাইলে OS-এর fsync লাগে
// standard C++-এ এর কোনো ফাংশন নেই

std::getline(in, line);   // "total,435"
// বাইটগুলো ফিরল; "435" লেখাটিকে
// আবার সংখ্যা বানাতে হবে — format-এর চুক্তি মেনে

৩ · ভুল ধরা — stream-এর অবস্থা আর eof()-এর বিখ্যাত ফাঁদ

একটি ফাইল খুলতে চাইলেন, কিন্তু নামটি ভুল, বা ফোল্ডারে পড়ার অনুমতি নেই। std::ifstream in{"sales.csv"}; কোনো exception ছোড়ে না, প্রোগ্রামও থামে না — শুধু stream-টি “ব্যর্থ” অবস্থায় চলে যায়, আর এরপর প্রতিটি পড়া নীরবে কিছুই করে না। আপনি যাচাই না করলে প্রোগ্রাম আনন্দে “আজ বিক্রি ০ টাকা” দেখাবে। তাই প্রথম নিয়ম: খোলার পরেই if (!in).

পর্ব ৭-এ cin-এর জন্য যে stream state দেখেছিলেন, ফাইলেও হুবহু তাই। চারটি প্রশ্ন করা যায়:

আর if (in) বা if (!in) লিখলে stream নিজেকে bool-এ রূপান্তর করে: true মানে !fail(). আরও সুন্দর ব্যাপার হলো, in >> x আর std::getline(in, line) দুটিই stream-টি নিজেকেই ফেরত দেয়। তাই while (in >> x) মানে: আগে পড়ার চেষ্টা, আর পড়া সফল হলে তবেই লুপের ভেতরে ঢোকা।

এখন সেই বাগটি, যা প্রায় প্রতিটি প্রোগ্রামার জীবনে অন্তত একবার লেখেন — আর AI এখনো প্রায়ই লেখে। একটি ফাইলে তিনটি বিক্রির অঙ্ক: 120, 75, 240, প্রতিটি নিজের লাইনে, শেষেও একটি newline. যোগফল হওয়া উচিত ৪৩৫. ধাপে ধাপে চালিয়ে দেখুন, প্রতিটি ধাপে আগে নিজে অনুমান করুন:

1std::ifstream f{"amounts.txt"};2while (!f.eof()) {3    f >> x;4    sum += x;5}6// ঠিক রূপ:7while (f >> x) sum += x;

getline দিয়ে while (!f.eof()) লিখলে বাগটি একটু অন্য চেহারায় আসে: শেষ পাকে getline কিছুই পায় না, line খালি হয়ে যায়, আর আপনার কোড একটি খালি লাইন প্রক্রিয়া করে — CSV পার্সার তখন “ভুল লাইন” বলে চিৎকার করে, বা আরও খারাপ, একটি শূন্য-দামের পণ্য খাতায় যোগ করে। আর ফাইলের শেষে newline না থাকলে বাগটি লুকিয়ে যায় — তাই পরীক্ষায় ধরা পড়ে না, ধরা পড়ে গ্রাহকের ফাইলে।

শুধু পড়াই নয়, লেখাও ব্যর্থ হতে পারে — ডিস্ক ভরে গেলে, পেনড্রাইভ খুলে নিলে, নেটওয়ার্ক ফোল্ডার হারিয়ে গেলে। লেখার পরে if (!out) দেখুন। কিন্তু একটি সূক্ষ্ম বিষয় আছে: buffer-এর শেষ অংশ ফাইলে যায় বন্ধ হওয়ার সময়, আর destructor সেই সময়ের ভুল আপনাকে জানাতে পারে না (destructor থেকে ভুল জানানোর ভালো উপায় নেই)। গুরুত্বপূর্ণ ফাইলে তাই নিজে out.close() ডেকে তারপর if (!out) দেখুন। চাইলে f.exceptions(std::ios::badbit) দিয়ে নির্দিষ্ট অবস্থায় stream-কে exception ছুড়তে বলা যায়, তবে বেশিরভাগ কোড অবস্থা দেখেই কাজ চালায়।

৪ · লাইন ধরে পড়া — দোকানের খাতা, CSV আর config ফাইল

বেশিরভাগ বাস্তব ফাইল লাইনভিত্তিক: প্রতি লাইনে একটি রেকর্ড। পড়ার নিরাপদ কৌশল দুই ধাপের — প্রথমে পুরো লাইন std::getline দিয়ে তুলে আনুন, তারপর সেই লাইনটিকে আলাদা করে পার্স করুন। সরাসরি ফাইলে >> চালালে একটি ভুল লাইন পুরো stream-কে fail অবস্থায় ফেলে দেয়, আর আপনি জানতেও পারেন না কোন লাইনে সমস্যা। লাইন আলাদা করে পড়লে একটি লাইন ভুল হলেও বাকিগুলো পড়া চলে, আর ভুল লাইনটি নাম ধরে জানানো যায়।

একটি লাইনকে ঘরে ভাগ করার দুটি জনপ্রিয় উপায়। std::istringstream একটি string-কে ছোট্ট একটি stream বানিয়ে দেয়, যাতে >> আর getline(row, item, ',') চালানো যায় — সহজ, পরিচিত। আর পর্ব ৪১-এর std::from_chars দ্রুততর, locale দেখে না, আর ঠিক কোথায় পড়া থামল তা জানায় — লাখ লাইনের ফাইলে বা কঠোর যাচাইয়ে সেটিই ভালো। এবার করিম ভাইয়ের দোকানের দিনের খাতা: লিখি, বন্ধ করি, আবার পড়ি — যার একটি লাইনে কেউ ভুল করে সংখ্যার জায়গায় x লিখে ফেলেছেন:

#include <fstream>
#include <print>
#include <sstream>
#include <string>
int main() {
    { std::ofstream out{"sales.csv"};                   // create or truncate
      std::print(out, "item,qty,price\ntea,12,10\nbiscuit,5,15\nchop,x,20\ncake,2,120\n"); }
    std::ifstream in{"sales.csv"};                      // closed above by RAII
    if (!in) { std::println("cannot open sales.csv"); return 1; }
    std::string line, item;
    std::getline(in, line);                             // skip the header
    int total = 0;
    while (std::getline(in, line)) {
        std::istringstream row{line};
        int qty = 0, price = 0; char comma = 0;
        if (std::getline(row, item, ',') && row >> qty >> comma >> price && comma == ',') {
            std::println("{:<8}{:>3} x {:>3} = {:>4}", item, qty, price, qty * price);
            total += qty * price;
        } else std::println("bad line: {}", line);
    }
    std::println("total = {} taka", total);
}

config ফাইল — key=value

অনেক অ্যাপ নিজের সেটিংস রাখে এমন একটি ফাইলে: lang=bn, vat=15, আর # দিয়ে শুরু লাইন মন্তব্য। পড়ার কাঠামো ওপরের মতোই — লাইন ধরে, তারপর ভাগ:

std::map<std::string, std::string> load_config(const std::filesystem::path& p) {
    std::map<std::string, std::string> cfg;
    std::ifstream in{p};
    if (!in) return cfg;                         // ফাইল নেই — ডিফল্ট সেটিংস চলবে
    std::string line;
    while (std::getline(in, line)) {
        if (line.empty() || line[0] == '#') continue;
        auto eq = line.find('=');
        if (eq == std::string::npos) continue;   // বা: লাইন নম্বরসহ সতর্কবার্তা
        cfg[line.substr(0, eq)] = line.substr(eq + 1);
    }
    return cfg;
}

লক্ষ করুন, ফাইল না থাকা এখানে ভুল নয় — প্রথমবার অ্যাপ চালালে config থাকবেই না। কোনটি “স্বাভাবিক অনুপস্থিতি” আর কোনটি “আসল ভুল”, সেই সিদ্ধান্ত আপনার নকশার অংশ। আরেকটি বাস্তব সমস্যা: Windows-এ Notepad দিয়ে সম্পাদিত ফাইলের লাইনের শেষে '\r' থেকে যেতে পারে (পরের অংশে কারণ), তখন "bn\r" আর "bn" মেলে না। ভালো loader মান থেকে দুই পাশের ফাঁকা জায়গা আর '\r' ছেঁটে নেয়।

পুরো ফাইল একবারে একটি string-এ

ছোট ফাইল (কয়েক MB পর্যন্ত) একবারে পড়ে নেওয়া প্রায়ই সবচেয়ে সরল। দুটি প্রচলিত রূপ:

std::ifstream in{"notice.txt", std::ios::binary};
std::string all{std::istreambuf_iterator<char>{in}, {}};   // শুরু থেকে শেষ পর্যন্ত সব বাইট

// অথবা: আকার জেনে একবারে পড়া (বড় ফাইলে দ্রুত)
std::string buf(std::filesystem::file_size("notice.txt"), '\0');
in.read(buf.data(), static_cast<std::streamsize>(buf.size()));

এখানে binary দেওয়া হয়েছে যাতে বাইটগুলো হুবহু আসে — আর আকার জেনে পড়ার সময় ফাইলের আকার আর পড়া বাইটের সংখ্যা যেন মেলে। তবে খেয়াল রাখুন, আকার জানা আর পড়ার মাঝে অন্য কেউ ফাইলটি বদলে দিতে পারে; তাই in.gcount() দিয়ে আসলে কত বাইট এল, তা দেখে নেওয়া ভালো অভ্যাস। আর ব্যবহারকারী যদি ১০ GB-র একটি ফাইল দেন? “সব একবারে RAM-এ” তখন আর সরল সমাধান নয় — লাইন ধরে পড়াই নিরাপদ।

৫ · text বনাম binary — newline, padding আর বাইটের ক্রম

“text mode” আর “binary mode”-এর পার্থক্য Linux বা macOS-এ প্রায় নেই, কিন্তু Windows-এ আছে। ইতিহাসটি টাইপরাইটারের: “লাইনের শুরুতে ফেরো” (carriage return, '\r') আর “এক লাইন নিচে নামো” (line feed, '\n') ছিল দুটি আলাদা কাজ। Windows (MS-DOS-এর উত্তরাধিকারে) লাইনের শেষ চিহ্ন হিসেবে দুটিই রাখে — \r\n; Unix শুধু \n. C আর C++ প্রোগ্রামের ভেতরে লাইন-শেষ সবসময় একটি '\n', তাই text mode-এ Windows-এর লাইব্রেরি লেখার সময় প্রতিটি \n-কে \r\n বানায় আর পড়ার সময় উল্টোটা করে। একে বলে newline translation.

• লেখা ফাইলের জন্য সুবিধা: আপনার কোড সব প্ল্যাটফর্মে একই, আর Windows-এর পুরোনো প্রোগ্রামও ফাইলটি ঠিকমতো দেখায়।
• অন্য সবকিছুর জন্য বিপদ: একটি ছবি বা সংখ্যার ফাইলে মান 10-এর বাইট আসলে “newline” নয়, শুধু একটি সংখ্যা। text mode সেটিকে দুই বাইট বানিয়ে ফাইল নষ্ট করবে। Windows-এর C লাইব্রেরি text mode-এ পড়ার সময় মান 26 (Ctrl+Z)-এর বাইটকে ফাইলের শেষও ধরে নিতে পারে। তাই লেখা নয় এমন সব ফাইলে binary mode.
• মিশ্র জগতে: Linux সার্ভারে Windows থেকে আসা CSV পড়লে প্রতিটি লাইনের শেষে '\r' থেকে যায়, কারণ Linux-এ কোনো রূপান্তর হয় না। টেকসই পার্সার এটা মেনে নেয়।

struct-এর বাইট সরাসরি লেখা — কেন এড়িয়ে চলবেন

binary ফাইলের সবচেয়ে লোভনীয় শর্টকাট — আর AI-এর প্রিয় — হলো একটি struct-এর মেমরি হুবহু ফাইলে ঢেলে দেওয়া:

struct Sale { char item[16]; int qty; double price; };

Sale s{"tea", 12, 10.0};
out.write(reinterpret_cast<const char*>(&s), sizeof s);   // এক লাইনে "সেভ"!
in.read(reinterpret_cast<char*>(&s), sizeof s);           // এক লাইনে "লোড"!

একই কম্পিউটারে, একই compiler-এ, একই সেটিংসে এটা কাজ করে — আর সেজন্যই ফাঁদ। ফাইলটি অন্য কোথাও নিলে বা কয়েক বছর পরে খুললে চারটি জিনিস ভাঙতে পারে:

1. Padding: qty-এর পরে double-কে ৮-এর গুণিতক ঠিকানায় বসাতে compiler হয়তো ৪টি ফাঁকা বাইট দিয়েছে। কয়টি, তা compiler আর প্ল্যাটফর্মের ওপর নির্ভর করে। সেই ফাঁকা বাইটে মেমরির পুরোনো আবর্জনাও ফাইলে চলে যায় — কখনো কখনো এমন তথ্য, যা বাইরে যাওয়ার কথা ছিল না।
2. মাপ: standard শুধু বলে int অন্তত ১৬ বিট; বেশিরভাগ জায়গায় ৩২ বিট, কিন্তু নিশ্চয়তা নেই। long Windows-এ ৩২ বিট, ৬৪-বিট Linux-এ ৬৪ বিট।
3. বাইটের ক্রম (endianness): 1000 সংখ্যাটি (hex 0x03E8) x86 আর বেশিরভাগ ARM-এ মেমরিতে থাকে E8 03 00 00 (little-endian), কিছু অন্য প্রসেসর আর নেটওয়ার্ক প্রোটোকলে 00 00 03 E8 (big-endian). ভুল ক্রমে পড়লে 1000 হয়ে যায় একটি বিশাল সংখ্যা।
4. নকশা বদল: পরের সংস্করণে struct-এ একটি discount ঘর যোগ করলেন — পুরোনো সব ফাইল এখন ভুলভাবে পড়বে, আর কোন ফাইল কোন সংস্করণের, বোঝার উপায় নেই। আর struct-এ যদি std::string বা pointer থাকে, ফাইলে যায় শুধু মেমরির ঠিকানা, আসল লেখা নয় — পরের বার চালালে সেই ঠিকানা অর্থহীন, পড়লেই undefined behavior.

সমাধান হলো নিজের format নিজে নির্ধারণ করা, আর প্রতিটি ঘর আলাদা করে লেখা-পড়া — একে বলে serialization. text হলে: ঘরের ক্রম, বিভাজক, সংখ্যার রূপ (দশমিক বিন্দু, locale-নিরপেক্ষ), আর প্রথম লাইনে একটি সংস্করণ বা শিরোনাম। binary হলে: প্রতিটি সংখ্যা নির্দিষ্ট মাপের টাইপে (std::uint32_t), নির্দিষ্ট বাইট-ক্রমে (C++20-এর std::endian দিয়ে জানা যায় নিজের যন্ত্রের ক্রম, C++23-এর std::byteswap দিয়ে উল্টানো যায়), ফাইলের শুরুতে একটি “magic” চিহ্ন আর সংস্করণ নম্বর। বড় প্রজেক্টে এই কাজের জন্য Protocol Buffers বা JSON-এর মতো প্রতিষ্ঠিত format আর লাইব্রেরিই সাধারণত ভালো পছন্দ।

৬ · std::filesystem — পথ, ফোল্ডার আর ভুলের দুই রকম খবর

ফাইলের ভেতরের বাইট পড়ে-লেখে stream; আর ফাইলের বাইরের প্রশ্ন — কোথায় আছে, আছে কি না, কত বড়, ফোল্ডারে আর কী আছে, কপি বা মোছা — এসবের জন্য C++17-এর std::filesystem (header <filesystem>). এর আগে এসব কাজে Windows-এ এক API, Linux-এ আরেক API লিখতে হতো। পর্ব ৪১-এ এর এক ঝলক দেখেছিলেন; এবার পুরো ছবি। সাধারণত লেখা হয় namespace fs = std::filesystem;.

path — string নয়, পথের নিজস্ব টাইপ

fs::path শুধু একটি string-এর মোড়ক নয়; এটি পথের অংশগুলো বোঝে। / অপারেটর দুটি অংশ জোড়ে আর প্রয়োজনমতো বিভাজক বসায়, তাই "C:\\data\\" + name-এর মতো হাতে জোড়ার দরকার নেই:

namespace fs = std::filesystem;
fs::path dir = "shop";
fs::path p = dir / "2026" / "sales.csv";   // shop/2026/sales.csv (Windows-এ \ দিয়ে)

p.filename();      // "sales.csv"
p.stem();          // "sales"
p.extension();     // ".csv"
p.parent_path();   // "shop/2026"
p.replace_extension(".bak");   // p এখন shop/2026/sales.bak

Windows নিজেও / বিভাজক মেনে নেয়, তাই সোজা / লেখা portable; কিন্তু "\\" শুধু Windows-এ বিভাজক, Linux-এ সেটা ফাইলের নামের একটি সাধারণ অক্ষর! তাই "reports\\jan.csv" Linux-এ একটি ফোল্ডার নয়, বরং অদ্ভুত নামের একটি ফাইল। নিয়ম সহজ: পথ জোড়ায় শুধু / অপারেটর।

প্রশ্ন আর কাজ — এক নজরে

ভুলের দুই রকম খবর — exception অথবা error_code

filesystem-এর প্রায় প্রতিটি ফাংশনের দুটি রূপ আছে। শেষে একটি std::error_code না দিলে ভুল হলে ছোড়ে fs::filesystem_error — একটি exception, যার ভেতরে ভুলের কোড (code()) আর জড়িত পথ (path1(), path2()) থাকে। শেষে std::error_code& দিলে কোনো exception নেই; ভুলটি সেই ভ্যারিয়েবলে লেখা হয়, আর আপনাকে নিজে দেখতে হয়।

এবার সব একসাথে: একটি ফোল্ডার তৈরি, তাতে তিনটি ফাইল নিরাপদ পদ্ধতিতে লেখা (পরের অংশে এর কারণ), শুধু .txt ফাইলগুলো আকারসহ তালিকা, আর exception ছাড়া একটি ভুল ধরা:

#include <algorithm>
#include <filesystem>
#include <fstream>
#include <print>
#include <vector>
namespace fs = std::filesystem;
int main() {
    const fs::path dir = fs::path{"shop"} / "notes";
    fs::create_directories(dir);                          // like mkdir -p
    for (std::string_view name : {"stock.txt", "dues.txt", "app.ini"}) {
        fs::path tmp = dir / name;  tmp += ".tmp";
        std::ofstream out{tmp};
        out << "data for " << name << '\n';
        out.close();                                      // flush now, then check
        if (!out) return 1;                               // never rename a broken file
        fs::rename(tmp, dir / name);                      // replace in one step
    }
    std::vector<std::pair<std::string, std::uintmax_t>> txt;
    for (const auto& e : fs::directory_iterator{dir})
        if (e.path().extension() == ".txt") txt.emplace_back(e.path().filename().string(), e.file_size());
    std::ranges::sort(txt);                               // directory order is unspecified
    for (const auto& [name, size] : txt) std::println("{:<10}{:>3} bytes", name, size);
    std::error_code ec;
    fs::rename(dir / "old.txt", dir / "x.txt", ec);       // no exception: error goes to ec
    std::println("old.txt not found? {}", ec == std::errc::no_such_file_or_directory);
}

একটি ফোল্ডারের ভেতরের সব ফোল্ডারসহ হাঁটতে চাইলে recursive_directory_iterator. এটি গাছের মতো কাঠামোয় কীভাবে এগোয়, দেখুন (নামের ক্রম এখানে একটি সম্ভাব্য উদাহরণ মাত্র):

1fs::recursive_directory_iterator it{"shop"};2for (; it != fs::end(it); ++it)3    if (it->is_regular_file())4        found.push_back(it->path());5std::ranges::sort(found);

৭ · নিরাপদে সেভ — temp ফাইলে লিখে তারপর rename

ধরুন করিম ভাইয়ের পুরো বছরের খাতা একটি ledger.csv-এ। অ্যাপ প্রতি সন্ধ্যায় নতুন হিসাবসহ পুরো ফাইলটি আবার লেখে: std::ofstream out{"ledger.csv"}; তারপর সব লাইন। ঠিক লেখার মাঝখানে লোডশেডিং হলো, আর UPS নেই। পরের দিন কী পাওয়া যাবে? ধাপে ধাপে দুটি কৌশল পাশাপাশি দেখুন:

ledger.csv      300 লাইন, পুরো বছরের সঠিক হিসাব

ledger.csv      0 বাইট   ← পুরোনো হিসাব এখনই শেষ
                         (একটি লাইনও লেখার আগে)

ledger.csv      ১৪০ লাইন, শেষ লাইন অর্ধেক কাটা
                পুরোনো ৩০০ লাইন? আর নেই।

ledger.csv      300 লাইন, সঠিক   ← কেউ ছোঁয়নি
ledger.csv.tmp  ১৪০ লাইন... crash!
পরের দিন: পুরোনো খাতা পুরো আছে, .tmp ফেলে দিন

ledger.csv      300 লাইন (পুরোনো)
ledger.csv.tmp  301 লাইন (নতুন, পুরো লেখা)
out.close(); if (!out) → rename করবেন না

ledger.csv      301 লাইন (নতুন)
যে কেউ যেকোনো মুহূর্তে খুললে পাবে:
পুরো পুরোনো, অথবা পুরো নতুন — অর্ধেক কখনো নয়

কয়েকটি শর্ত মনে রাখুন। temp ফাইল একই ফোল্ডারে রাখুন — rename শুধু একই ফাইল সিস্টেমের ভেতরে এক ধাপে কাজ করে; অন্য ডিস্কে (যেমন সিস্টেমের temp ফোল্ডার আলাদা partition-এ থাকলে) সেটা ব্যর্থ হয়, আর তখন কপি করে মোছা আর atomic নয়। temp ফাইলের নাম অনন্য রাখুন, যাতে একই অ্যাপের দুটি কপি একে অপরের temp ফাইল মুছে না দেয়। Windows-এ std::filesystem::rename সাধারণত বিদ্যমান ফাইল প্রতিস্থাপন করে, আর বাস্তবে এক ধাপেই ঘটে, তবে POSIX-এর মতো আনুষ্ঠানিক atomic নিশ্চয়তা নথিতে নেই — আর অন্য প্রোগ্রাম ফাইলটি খুলে রাখলে rename ব্যর্থ হতে পারে। তাই rename-এর ফলও যাচাই করুন।

এই কৌশল কোথায় লাগে না? লগ ফাইলে — সেখানে আপনি শুধু শেষে যোগ করেন (app), পুরোনো লেখা ছোঁয়া হয় না, তাই crash হলে বড়জোর শেষ লাইনটি অসম্পূর্ণ থাকে। আর কোথায় এটা যথেষ্ট নয়? যেখানে প্রতি সেকেন্ডে শত শত ছোট হালনাগাদ, বা একাধিক প্রোগ্রাম একসাথে লেখে — সেখানে পুরো ফাইল বারবার লেখা অসম্ভব রকম ধীর। তখন SQLite-এর মতো একটি ডেটাবেস ব্যবহার করুন, যা journal দিয়ে এই সমস্যার পূর্ণ সমাধান করে রেখেছে।

৮ · বাংলা নামের ফাইল, Unicode আর ব্যবহারকারীর দেওয়া পথ

করিম ভাই চান ফাইলের নাম হোক হিসাব.csv. শুনতে সহজ, কিন্তু এখানে অপারেটিং সিস্টেমগুলোর ভেতরের পার্থক্য সামনে চলে আসে। Linux আর macOS-এ ফাইলের নাম হলো বাইটের সারি, আর প্রচলিত নিয়মে সেগুলো UTF-8: প্রতিটি বাংলা অক্ষর তিন বাইট। Windows-এ ফাইলের নাম রাখা হয় UTF-16-এ — ১৬-বিটের একক — আর তাই সেখানে fs::path-এর ভেতরের অক্ষর-টাইপ wchar_t, Linux-এ char.

• কীভাবে বানাবেন: C++20 থেকে fs::path p{u8"হিসাব.csv"}; — u8 literal-এর টাইপ char8_t, আর path জানে এটি UTF-8, তাই সব প্ল্যাটফর্মে সঠিক নাম হয়। C++17-এর fs::u8path() একই কাজ করত, কিন্তু C++20-এ deprecated.
• কীভাবে ফেরত নেবেন: p.string() দেয় প্ল্যাটফর্মের “স্থানীয়” narrow encoding-এ। Linux-এ সাধারণত UTF-8, কিন্তু Windows-এ পুরোনো ANSI code page, যেখানে বাংলা অক্ষর নেই — রূপান্তর ব্যর্থ হয়ে exception বা বিকৃত নাম আসতে পারে। নিশ্চিত UTF-8 চাইলে p.u8string() (C++20-এ এটি std::u8string ফেরত দেয়), আর Windows-এর নিজের API-তে দিতে p.native() বা p.wstring().
• বাইট গোনা বনাম অক্ষর গোনা: Linux-এ u8"হিসাব.csv"-এর filename().string().size() হয় 19 — “হিসাব”-এর পাঁচটি Unicode অক্ষর (হ, ি, স, া, ব) × ৩ বাইট, যোগ .csv-এর ৪. “নামটি ২০ অক্ষরের বেশি নয়” যাচাই করতে বাইট গুনলে ভুল হবে।

কনসোলে বাংলা প্রিন্ট করাও আলাদা প্রশ্ন — terminal-এর encoding ঠিক না থাকলে সঠিক নামও প্রশ্নবোধক চিহ্ন হয়ে দেখায়। ফাইলের নাম ঠিক আছে কি না যাচাই করতে কনসোলের ছবির ওপর ভরসা না করে fs::exists দিয়ে দেখুন।

ব্যবহারকারীর দেওয়া পথ — বিশ্বাস নয়, যাচাই

ধরুন একটি ওয়েব সার্ভিস ব্যবহারকারীকে রিপোর্ট ডাউনলোড করতে দেয়: reports_dir / user_input. ব্যবহারকারী যদি নাম পাঠান ../config/secret.ini? .. মানে “এক ফোল্ডার ওপরে”, তাই পথটি আপনার রিপোর্ট ফোল্ডার থেকে বেরিয়ে অন্য জায়গায় চলে যায়। একে বলে path traversal. আরও সূক্ষ্ম একটি ফাঁদ fs::path-এর নিজের নিয়মে: ডান দিকের অংশ যদি পূর্ণ পথ (absolute) হয়, / বাঁ দিকটা ফেলে দেয় — fs::path{"data"} / "/etc/passwd"-এর ফল শুধু /etc/passwd.

• নীতি ১ — যতটা সম্ভব পথ নেবেন না, নাম নেবেন: ব্যবহারকারী একটি আইডি বা নাম দেবেন; আপনি নিজের তালিকা থেকে আসল ফাইল খুঁজবেন। শুধু অক্ষর, সংখ্যা, - আর _ অনুমোদন করা (allowlist) সবচেয়ে সরল প্রতিরক্ষা।
• নীতি ২ — পথ নিতেই হলে আগে নিয়মিত রূপে আনুন, তারপর সীমা দেখুন: fs::weakly_canonical বা fs::canonical (canonical path) .., . আর symlink মিটিয়ে আসল পূর্ণ পথ দেয়। সেই পথটি আপনার অনুমোদিত ফোল্ডারের ভেতরে কি না, অংশ ধরে মিলিয়ে দেখুন — শুধু string-এর শুরু মিলিয়ে নয়, কারণ /data/reports2-ও /data/reports দিয়ে শুরু হয়।
• নীতি ৩ — যাচাই আর ব্যবহারের মাঝের সময় মনে রাখুন: যাচাইয়ের পরে কেউ ফাইলের জায়গায় symlink বসিয়ে দিতে পারে। নিরাপত্তা-সংবেদনশীল সার্ভারে প্রোগ্রামকে সীমিত অনুমতিতে চালানো আর অপারেটিং সিস্টেমের সুরক্ষা ব্যবহার করাই শেষ প্রতিরক্ষা।

৯ · AI-এর যুগে — ফাইলের কোডে AI-এর চেনা ভুল

ফাইলের কোড AI খুব দ্রুত লেখে, আর প্রথম দেখায় সেটি ঠিকঠাক চলে — কারণ পরীক্ষার সময় ফাইলটি থাকে, ডিস্ক খালি থাকে, কেউ বিদ্যুৎ বন্ধ করে না। ভুলগুলো লুকিয়ে থাকে “অসুখী পথে”: ফাইল নেই, শেষ লাইনে newline নেই, Windows থেকে আসা \r, ভরা ডিস্ক, বাংলা নাম। ইন্টারনেটের পুরোনো উদাহরণ থেকে শেখা AI-এর চেনা ভুলগুলো:

AI-এর লেখা ফাইল-কোড যাচাইয়ের চেকলিস্ট

• কোডে eof() খুঁজেছি — লুপের শর্তে কোথাও নেই; পড়ার কাজটিই শর্ত
• প্রতিটি ফাইল খোলার পরে if (!f) আছে, আর গুরুত্বপূর্ণ লেখার পরে close() করে অবস্থা দেখা হয়েছে
• reinterpret_cast দিয়ে struct বা object-এর বাইট ফাইলে যাচ্ছে না; format লিখিতভাবে নির্ধারিত
• পথ জোড়া হয়েছে fs::path আর / দিয়ে; ব্যবহারকারীর দেওয়া অংশ যাচাই করা হয়েছে
• প্রতিটি error_code দেখা হয়েছে, অথবা filesystem_error কোথাও ধরা হয়েছে
• নিজে চালিয়ে দেখেছি: ফাইল নেই, খালি ফাইল, শেষে newline নেই, একটি ভুল লাইন, আর বাংলা নামের ফাইল