ساختار فایل سیستم لینوکس چیست؟ آموزش پوشه‌های etc/ تا var/

ببین، فرض کن برای اولین بار وارد یه سرور لینوکسی شدی و می‌گن دیشب پشتیبان‌گیری انجام نشده. برنامه کجا نصب شده؟ تنظیماتش کجاست؟ لاگش رو از کجا باید بخونی؟ اگه فقط ls و cd بلد باشی، احتمالاً شروع می‌کنی همه پوشه‌ها رو یکی‌یکی گشتن. اما وقتی ساختار فایل سیستم لینوکس رو بشناسی، می‌فهمی برای هر سؤال از کدوم مسیر شروع کنی و چطور بدون دست زدن به فایل‌های مهم، سرنخ پیدا کنی.

توی این آموزش فایل سیستم لینوکس قرار نیست اسم چندتا پوشه رو حفظ کنیم و بریم سراغ درس بعدی. با هم می‌بینیم چرا مسیرها از / شروع می‌شن، تفاوت /etc و /var چیه و چرا /home، /usr و /tmp هرکدوم کار خودشون رو دارن. بعدش با یه پرونده عیب‌یابی فرضی جلو می‌ریم و نمونه کوچیکی از ساختار پوشه‌های لینوکس رو توی حساب خودت می‌سازیم.

اگر تازه آموزش لینوکس از صفر رو شروع کردی، این درس دقیقاً برای توئه. فقط بهتره بدونی فایل و پوشه چیه و چطور چند فرمان ساده توی ترمینال اجرا می‌شه. همه مثال‌ها رو برای مسیرهای مشخص و با حداقل خطر چیدم؛ یعنی قرار نیست برای تمرین، تنظیمات واقعی سیستم رو تغییر بدی یا هرجا دسترسی نداشتی sudo بزنی. هر خروجی هم که به نسخه یا توزیع وابسته باشه، همون‌جا توضیح می‌دم.

ساختار فایل سیستم لینوکس چیست؟ یک جواب کوتاه و کاربردی

اول جواب سؤال اصلی رو روشن کنیم: ساختار فایل سیستم لینوکس یعنی فایل‌ها و دایرکتوری‌های یک سیستم معمولاً با چه منطقی کنار هم قرار می‌گیرن. اصطلاح انگلیسیش Linux Filesystem Hierarchy هست. مثلاً وقتی دنبال تنظیمات عمومی می‌گردی، /etc یکی از اولین جاهاییه که بررسی می‌کنی؛ برای داده‌های متغیر و لاگ‌ها اغلب سراغ /var می‌ری و فایل‌های شخصی رو معمولاً در پوشه خانگی پیدا می‌کنی. این قراردادها کار پیدا کردن و نگهداری فایل‌ها رو راحت‌تر می‌کنن.

حواست باشه یه سؤال دیگه هم داریم که اسمش شبیه همینه: «فایل سیستم لینوکس چیست و چه نوع‌هایی داره؟» وقتی حرف از ext4، XFS یا Btrfs می‌زنیم، داریم درباره روش ذخیره و مدیریت داده روی فایل‌سیستم صحبت می‌کنیم؛ نه درباره جای پوشه /etc. ساختار دایرکتوری لینوکس یه درخت واحد از مسیرهاست، ولی پشت همین درخت ممکنه چند فایل‌سیستم و حتی چند دیسک متفاوت وجود داشته باشه. این دو مفهوم رو از همین اول از هم جدا کن.

البته این نقشه، قانون صددرصدی برای تک‌تک توزیع‌ها نیست. یه مسیر ممکنه توی اوبونتو وجود داشته باشه و توی یه کانتینر مینیمال اصلاً نباشه؛ ممکنه هم به جای پوشه واقعی، لینک نمادین باشه. پس وقتی درباره ساختار لینوکس صحبت می‌کنیم، اسم دایرکتوری فقط سرنخه. تصمیم نهایی رو باید با مشاهده همون سیستمی بگیری که جلوت بازه، نه با فرض اینکه همه ماشین‌ها عین عکس مقاله هستن.

ریشه / در لینوکس کجاست و چه فرقی با درایوهای ویندوز داره؟

اگه با ویندوز کار کرده باشی، احتمالاً به مسیرهایی مثل C:\Users و D:\Projects عادت داری. توی لینوکس، آدرس‌دهی از یه ریشه به نام / شروع می‌شه؛ بعد همه مسیرها زیر همون درخت دیده می‌شن. این یعنی فایل‌های روی دیسک‌های جدا هم می‌تونن با یه آدرس مشترک در دسترس باشن، مثلاً وقتی یه فایل‌سیستم روی /mnt/archive متصل شده. پس «یک درخت مسیر» رو با «یک دیسک فیزیکی» اشتباه نگیر.

یه نکته هست که خیلی‌ها رو گیج می‌کنه: / و /root یکی نیستن. اولی ریشه همه مسیرهاست و دومی در خیلی از توزیع‌ها پوشه خانگی کاربر مدیر محسوب می‌شه. ممکنه حساب عادی تو پوشه‌ای مثل /home/student داشته باشه. همین تفاوت root و home در لینوکس رو الان یاد بگیر تا بعدها وقتی با مسیر فایل‌ها و دسترسی‌ها سروکار داری، منظور از «روت» رو اشتباه برداشت نکنی.

printf "مسیر فعلی: "
pwd
printf "پوشه خانگی: %s\n" "$HOME"
printf "فهرست سطح اول: "
ls -1 / | head -n 12

این دستورها هیچ فایلی رو تغییر نمی‌دن؛ فقط محل فعلی و چند ورودی سطح اول رو نشون می‌دن. ممکنه خروجی ls / روی WSL، ماشین مجازی و سرور با هم فرق کنه و کاملاً هم طبیعی باشه. به جای مقایسه مو‌به‌موی اسم‌ها، سه چیز رو بررسی کن: pwd الان کجا هستی، HOME خونه کاربر کجاست و / از کجا درخت فایل‌ها رو شروع می‌کنه. برای این مشاهده هیچ نیازی به sudo نیست.

استاندارد FHS چیست و چقدر باید به اون تکیه کنیم؟

حالا برسیم به اینکه استاندارد FHS چیست. این اسم مخفف Filesystem Hierarchy Standard هست؛ سندی که درباره نقش مسیرهای متداول لینوکس مثل /etc، /usr و /var توضیح می‌ده. وقتی در یه آموزش می‌بینی از ساختار فایل سیستم لینوکس حرف می‌زنن، معمولاً همین قراردادهای رایج رو در نظر دارن. اما FHS تضمین نمی‌کنه همه توزیع‌ها دقیقاً یک چیدمان داشته باشن؛ پیاده‌سازی‌های جدید ممکنه بعضی مسیرها رو متفاوت ارائه بدن.

مثلاً شاید جایی خونده باشی /bin و /usr/bin دو پوشه کاملاً جدا هستن. این حرف برای همه سیستم‌های جدید درست نیست. در خیلی از توزیع‌ها از طرح merged-/usr استفاده می‌شه و /bin می‌تونه به /usr/bin لینک شده باشه. یعنی دیدن دو اسم الزاماً معنی دو کپی متفاوت از یه برنامه رو نمی‌ده. اگر کنجکاوی، توضیح رسمی Debian درباره ادغام مسیرهای usr دقیقاً همین موضوع رو باز می‌کنه.

ببین، مستندات برای پیدا کردن نقطه شروع عالی‌ان، ولی جای مشاهده سیستم خودت رو نمی‌گیرن. من موقع آموزش فایل سیستم لینوکس ترجیح می‌دم سه چیز رو از هم جدا کنی: اون چیزی که استاندارد پیشنهاد داده، اون چیزی که توزیعت پیاده کرده و اون چیزی که همین الان روی ماشین وجود داره. اگه این سه رو قاطی نکنی، موقع عیب‌یابی کمتر دنبال پوشه‌ای می‌گردی که از اول قرار نبوده روی سیستمت وجود داشته باشه.

ساختار پوشه‌های لینوکس؛ یه نقشه سریع برای پیدا کردن فایل‌ها

برای یاد گرفتن پوشه‌های لینوکس یه راه بهتر از حفظ کردن فهرست الفبایی وجود داره: اول ببین دنبال چه نوع اطلاعاتی هستی. فایل شخصیه؟ تنظیمات برنامه‌ست؟ لاگ و وضعیت سرویسه؟ یا اطلاعات موقتیه؟ جدول پایین یه نقشه سریع از ساختار پوشه‌های لینوکس بهت می‌ده. لازم نیست همین لحظه همه مسیرها رو حفظ کنی؛ فقط موقع برخورد با هر مسئله، حدس اولیه‌ات رو بر اساس نقش اون مسیر بساز.

پوشه etc در لینوکس؛ تنظیمات سیستم رو از کجا پیدا کنیم؟

وقتی برنامه‌ای درست رفتار نمی‌کنه، یکی از سؤال‌های خوب اینه که «تنظیماتش رو از کجا می‌خونه؟». پوشه etc در لینوکس که معمولاً به شکل /etc می‌نویسیم، محل متداول تنظیمات سراسری مربوط به ماشینه. برای نمونه /etc/hosts در خیلی از سیستم‌ها نگاشت محلی نام و نشانی رو نگه می‌داره. اما این به معنی نیست که تنظیمات همه برنامه‌ها حتماً همین‌جاست؛ بعضی‌ها تنظیمات مخصوص هر کاربر یا مسیر اختصاصی خودشون رو دارن.

فرض کن دو نفر روی یک لپ‌تاپ با یه برنامه کار می‌کنن، ولی تنظیمات اون برنامه براشون یکسان نیست. شاید تنظیمات عمومی در /etc مشترک باشه، اما هر نفر یه فایل پیکربندی توی پوشه خانگی خودش داشته باشه. پس اگه دنبال علت اختلاف هستی، فقط ساختار پوشه‌های لینوکس رو از حفظ نگو؛ اول بپرس تنظیمات مورد نظر «سراسری» هست یا «مخصوص کاربر». همین یک سؤال می‌تونه کلی جست‌وجوی بی‌فایده رو کم کنه.

برای دیدن چند نمونه از /etc لازم نیست چیزی رو ویرایش کنی. اول مسیر و فایل عمومی hosts رو ببین، بعد درباره معنای خروجی فکر کن. اجرای دستور با دسترسی مدیر فقط به خاطر کنجکاوی ایده خوبی نیست؛ بعضی فایل‌های تنظیمات اطلاعات حساس دارن و بعضی تغییرها می‌تونن سرویس رو از کار بندازن. فعلاً هدف این بخش شناخت آدرس‌هاست، نه دست‌کاری تنظیمات سیستم.

ls -ld /etc
ls -l /etc/hosts
cat /etc/hosts

با این سه فرمان فقط شکل مسیر و محتوای عمومی /etc/hosts رو می‌بینی؛ چیزی تغییر نمی‌کنه. ممکنه روی WSL یا یه ماشین مجازی، این فایل با نمونه مقاله فرق داشته باشه. اتفاقاً هدفمون از آموزش ساختار فایل سیستم لینوکس همین مشاهده تفاوت‌هاست. از وجود چند خط در فایل hosts هم نمی‌شه نتیجه گرفت همه نام‌ها فقط از همین روش Resolve می‌شن؛ سیستم ممکنه تنظیمات Resolver دیگه‌ای داشته باشه.

پوشه home در لینوکس؛ فایل‌های شخصی رو کجا نگه داریم؟

حالا نوبت پوشه home در لینوکسه. خیلی از توزیع‌ها فایل‌های شخصی هر کاربر رو زیر /home/username نگه می‌دارن؛ ولی بهتره این مسیر رو برای همه سیستم‌ها قطعی ندونی. متغیر $HOME بهت می‌گه پوشه خانگی همین نشست کجاست. این موضوع توی WSL، کانتینر و سرورهای دارای حساب‌های ویژه مهمه، چون ممکنه مسیر واقعی با چیزی که از روی اسم کاربر حدس می‌زنی فرق داشته باشه.

توی پوشه خانگی فقط عکس و پروژه شخصی نیست. فایل‌هایی مثل .bashrc و پوشه .config ممکنه تنظیمات برنامه‌ها رو نگه دارن. اسم‌شون چون با نقطه شروع شده، در نمایش عادی ls پنهان می‌مونن؛ ولی پنهان بودن با رمزگذاری یا کنترل دسترسی یکی نیست. وقتی ساختار فایل سیستم لینوکس رو یاد می‌گیری، این فرق رو هم باید بفهمی تا به اشتباه فایل مخفی رو فایل امن فرض نکنی.

printf "HOME=%s\n" "$HOME"
ls -ld "$HOME"
ls -a "$HOME" | head -n 12

یه قانون خوب از همین اول اینه که فایل رو جایی بذاری که با نقش اون هماهنگ باشه. فایل تمرین خودت طبیعتاً داخل HOME منطقی‌تره، نه توی پوشه‌های سیستمی. برعکس، قرار نیست هر سرویس یا دیتابیس واقعی رو صرفاً چون کاربرش رو می‌شناسی داخل خانه اون کاربر نگه داری. ساختار فایل سیستم لینوکس برای اینه که موقع انتخاب مسیر به نوع داده، دسترسی، نگهداری و پشتیبان‌گیری هم فکر کنی؛ نه فقط به راحتی تایپ کردن اسم پوشه.

تفاوت root و home در لینوکس؛ سه مفهوم که نباید قاطی کنیم

بذار این سه مفهوم رو کنار هم بذاریم. ریشه / نقطه شروع درخت مسیرهاست، حساب root یه کاربر با اختیارات مدیریتیه و /root هم معمولاً پوشه خانگی همون کاربره. در مقابل، /home اغلب برای پوشه‌های شخصی کاربران عادی استفاده می‌شه. وقتی کسی درباره تفاوت root و home در لینوکس سؤال می‌کنه، معمولاً همین مفاهیم رو قاطی کرده. یه بار این فرق رو خوب بفهم تا بعداً با خطای Permission سراغ مسیر اشتباه نری.

اگه کاربر معمولی هستی و اجازه ورود به /root رو نداری، لزوماً هیچ مشکلی پیش نیومده. خیلی از توزیع‌ها دسترسی به خانه کاربر مدیر رو محدود می‌کنن و این دقیقاً همون رفتاریه که انتظار داریم. شناخت ساختار فایل سیستم لینوکس قرار نیست بهت اجازه تغییر همه فایل‌ها رو بده؛ کمک می‌کنه بدونی هر مسیر متعلق به چه کاریه. جزئیات مجوز فایل‌ها و پوشه‌ها رو در درس بعدی تمرین می‌کنیم.

پوشه usr در لینوکس؛ محل برنامه‌ها، نه فایل‌های شخصی

اسم /usr یه کم گول‌زننده‌ست؛ بعضی‌ها فکر می‌کنن چون شبیه User هست، پس باید فایل‌های خودشون رو اونجا بذارن. اما پوشه usr در لینوکس معمولاً محل برنامه‌ها، کتابخانه‌ها و منابعی هست که همراه سیستم یا بسته‌ها نصب می‌شن. برای مثال خیلی از فرمان‌ها در /usr/bin هستن و فایل‌های مستقل از معماری و راهنماها اغلب توی /usr/share پیدا می‌شن. برای پروژه شخصی‌ات به جای این مسیر از پوشه خانگی استفاده کن.

می‌خوای بدونی ls از کجا اجرا می‌شه؟ لازم نیست مسیرش رو حدس بزنی؛ command -v ls رو بزن و جواب همون محیط رو ببین. برای بعضی فرمان‌ها خروجی مسیر یه فایل اجراییه و برای بعضی‌ها ممکنه رفتار متفاوتی باشه. ساختار فایل سیستم لینوکس یه نقشه کلی در اختیارت می‌ذاره، اما اینکه یه برنامه دقیقاً کجا نصب شده به توزیع، مدیر بسته و تنظیمات PATH هم بستگی داره.

command -v ls
command -v bash
ls -ld /usr /usr/bin /usr/share

اینجا /usr/local رو هم از /usr جدا کن. طبق قرارداد، اولی برای بخشی از نرم‌افزارها و فایل‌هاییه که مدیر سیستم به شکل محلی اضافه می‌کنه؛ در حالی که بخش بزرگی از /usr زیر مدیریت بسته‌های توزیعه. البته روش نصب برنامه‌ها یکی نیست و نمی‌شه از روی اسم یه مسیر درباره هر نصب نتیجه قطعی گرفت. همین ریزه‌کاری‌های ساختار فایل سیستم لینوکس بعدها موقع ارتقا یا حذف برنامه جلوی قاطی شدن فایل‌های خودت با فایل‌های سیستم رو می‌گیره.

چرا /bin گاهی به /usr/bin اشاره می‌کنه؟

روی خیلی از سیستم‌های جدید، چیزی به نام merged-/usr وجود داره. به‌جای نگهداری دو مجموعه مستقل از فایل‌های اجرایی، مسیر قدیمی /bin ممکنه لینک نمادین به /usr/bin باشه. برای همین اگر در دو آدرس مختلف یک فایل اجرایی دیدی، لزوماً به معنی نصب دوباره برنامه نیست. در بعضی توزیع‌ها درباره /sbin و /lib هم شکل‌هایی از همین سازگاری وجود داره؛ ولی نباید نوع همه لینک‌ها رو بدون بررسی قطعی فرض کنی.

ls -ld /bin /sbin 2>/dev/null
readlink -f /bin
readlink -f /usr/bin

اگر خروجی readlink -f /bin و readlink -f /usr/bin یکسان شد، در همین سیستم هر دو مسیر به مقصد یکسانی می‌رسن. اگر متفاوت بود هم فوراً نتیجه نگیر سیستم خرابه؛ بعضی محیط‌ها ساختار متفاوتی دارن. یک قانون ایمن اینه که هرگز برای «مرتب کردن» لینوکس، پوشه‌های /bin یا /usr/bin رو دستی جابه‌جا یا حذف نکنی. ساختار این مسیرها معمولاً توسط بسته‌های سیستم و ابزارهای توزیع مدیریت می‌شه.

پوشه var در لینوکس؛ لاگ‌ها و داده‌های متغیر کجان؟

حالا برسیم به پوشه var در لینوکس. اگه /etc رو جای پیدا کردن سرنخ تنظیمات بدونیم، /var معمولاً محل داده‌هاییه که حین کار برنامه‌ها تغییر می‌کنن. ممکنه داخلش گزارش خطا، کش، صف پردازش و اطلاعات وضعیت سرویس‌ها باشه. همین تنوع باعث می‌شه هنگام عیب‌یابی یا پر شدن فضای ذخیره‌سازی، /var یکی از مسیرهای مهم ساختار فایل سیستم لینوکس باشه؛ البته وجود یه پوشه به‌تنهایی اثبات نمی‌کنه مشکل از اونجاست.

فرض کن یه سرویس هنوز جواب می‌ده، اما دیگه نمی‌تونه داده جدید ذخیره کنه. ممکنه فایل اجرایی سالم باشه و مشکل از فضای ذخیره‌سازی، مجوز نوشتن یا محل داده‌های متغیر شروع شده باشه. اینجا ساختار فایل سیستم لینوکس بهت می‌گه /var رو هم در فهرست بررسی بذاری؛ نه اینکه بدون مدرک اعلام کنی قطعاً مشکل اونجاست. اول نشانه‌ها رو جمع کن، بعد درباره تغییر تنظیمات یا پاک کردن فایل تصمیم بگیر.

پوشه /var/log؛ گزارش‌ها همیشه یک فایل ساده نیستن

خیلی از سرویس‌ها گزارش‌هاشون رو در /var/log ثبت می‌کنن، ولی همه رخدادها الزاماً یه فایل متنی با اسم ثابت نیستن. مثلاً ممکنه بخشی از لاگ‌ها در Journal سیستم نگهداری بشه و مسیر ذخیره‌سازی هم به تنظیمات وابسته باشه. پس اگه ساختار فایل سیستم لینوکس رو می‌شناسی ولی فایل syslog رو پیدا نکردی، لزوماً سیستم خرابه؟ نه. باید ببینی همون سرویس از چه سازوکار ثبت گزارشی استفاده می‌کنه.

برای مبتدی‌ها بهترین قدم اینه که اول از وجود مسیرها مطمئن بشن و فقط اطلاعاتی رو ببینن که مجوزش رو دارن. باز کردن فایل‌های حساس یا تلاش برای دور زدن مجوزها بخشی از این تمرین نیست. اگر دسترسی به یک لاگ مجاز نبود، معنی‌اش این نیست که باید با sudo همه‌چیز رو بخونی؛ در سیستم کاری باید طبق نقش و سیاست سازمان دسترسی بگیری.

ls -ld /var /var/log /var/lib /var/cache
ls -1 /var/log 2>/dev/null | head -n 12
df -h "$HOME"

دستور df مقدار فضای فایل‌سیستمی رو که پوشه خانگی روی اون قرار داره نمایش می‌ده، نه حجم تک‌تک فایل‌های داخل خانه رو. اگر /var روی فایل‌سیستم جداگانه باشه، وضعیتش ممکنه متفاوت باشه. این تفاوت رو در مدیریت سرور جدی بگیر: درخت مسیرها یکیه، اما همه پوشه‌ها الزاماً روی یک پارتیشن یا حتی یک دیسک قرار ندارن.

فرق /var/lib، /var/cache و /var/spool چیه؟

یه اشتباه رایج اینه که همه فایل‌های زیر /var رو «لاگ» یا «کش» بدونیم. در حالی که /var/lib می‌تونه داده پایدار و حیاتی برنامه رو نگه داره، /var/cache معمولاً برای داده کمکی قابل بازسازی استفاده می‌شه و /var/spool ممکنه شامل کارهای منتظر پردازش باشه. پس قبل از پاک کردن هر چیزی، دقیقاً مشخص کن با کدوم دسته از داده‌ها طرفی. آشنایی با ساختار دایرکتوری لینوکس یعنی همین تفاوت‌های کاربردی رو بدونی.

وقتی دیسک پر می‌شه وسوسه‌انگیزه بگی «بی‌خیال، چند تا فایل زیر /var رو پاک می‌کنم». این کار ممکنه لاگ لازم برای تشخیص مشکل یا داده پایدار برنامه رو از بین ببره. درک ساختار فایل سیستم لینوکس یعنی بدونی /var/lib با /var/cache یکی نیست و حتی فایل‌های کش هم بدون بررسی نباید کورکورانه حذف بشن. اول مصرف واقعی فضا و برنامه مسئولش رو پیدا کن؛ بعد سراغ راه‌حل مستند برو.

پوشه tmp در لینوکس و تفاوتش با /var/tmp

اسم این دو مسیر شبیهه ولی نقش‌شون دقیقاً یکی نیست. پوشه tmp در لینوکس یعنی /tmp برای داده‌های موقتیه که نباید روی موندنشون حساب باز کنی. /var/tmp طبق FHS برای فایل‌های موقتی با دوام بیشتر، از جمله موندن بعد از راه‌اندازی دوباره، در نظر گرفته شده. ولی این هم قول نگهداری دائمی نیست؛ سیستم می‌تونه بر اساس سیاست پاک‌سازی، فایل‌ها رو بعداً حذف کنه. خلاصه، هیچ‌کدوم رو جای تنها نسخه فایل مهمت انتخاب نکن.

یه توصیه کاربردی: فایل مهم، رمز عبور یا تنها نسخه بکاپ رو داخل /tmp و /var/tmp نگه ندار. حتی اگر الان فایل چند روز اونجا مونده، هیچ تضمینی نیست بعداً هم باقی بمونه. در ساختار فایل سیستم لینوکس اسم Temporary خودش یه هشدار درباره چرخه عمر داده‌ست. تازه ممکنه یکی از این مسیرها روی حافظه موقت باشه و دیگری روی دیسک؛ باید وضعیت همون ماشین رو بررسی کنی.

برای یک تجربه ساده می‌تونی مسیر /tmp رو مشاهده کنی، اما تمرین‌های ساخت و حذف فایل رو داخل پوشه مخصوص خودت انجام بدی. این انتخاب عمداً محافظه‌کارانه‌ست: هدف شناخت معماری لینوکسه، نه تمرین پاک‌سازی مسیرهای اشتراکی سیستم. بعداً وقتی وارد مدیریت سرویس‌ها شدی، درباره فایل‌های موقت و سیاست‌های زمان‌بندی پاک‌سازی عمیق‌تر یاد می‌گیری.

پوشه /run؛ وضعیت لحظه‌ای سرویس‌ها و تفاوتش با داده ماندگار

بعضی اطلاعات فقط تا وقتی سیستم روشنه معنی دارن؛ مثلاً شناسه اجرای یه فرایند یا سوکت ارتباطی یه سرویس. پوشه /run توی خیلی از سیستم‌های مدرن برای همین داده‌های زمان اجراست و بعد از بوت دوباره محتواش از نو ساخته می‌شه. این بخش از ساختار فایل سیستم لینوکس رو نباید با /var/lib که معمولاً جای داده‌های ماندگار برنامه‌ست یکی بگیری؛ چون در عیب‌یابی نتیجه کاملاً متفاوتی می‌گیری.

ممکنه در بعضی سیستم‌ها مسیر /var/run هم ببینی که برای سازگاری به /run اشاره می‌کنه. این هم یکی از مواردیه که مقایسه پوشه‌ها بدون توجه به لینک‌های نمادین گمراه‌کننده می‌شه. اگر یک سرویس بعد از روشن شدن سیستم نتونست فایل زمان اجرای خودش رو بسازه، موضوع قابل بررسیه، اما پاسخ صحیح لزوماً تغییر دستی فایل‌ها یا دادن دسترسی کامل به همه کاربران نیست.

ls -ld /run
if [ -e /var/run ]; then readlink -f /var/run; fi

این خروجی فقط وضعیت مسیرهای موجود رو نشون می‌ده و هیچ فایلی رو تغییر نمی‌ده. توجه کن که محیط‌هایی مثل برخی کانتینرها یا WSL ممکنه نمونه کاملی از رفتار سرویس‌های یک سیستم لینوکسی سنتی نباشن. برای همین بهتره نتیجه مشاهده رو به محیطی که دستور روی اون اجرا شده محدود کنی.

پوشه‌های /dev، /proc و /sys؛ چرا همه فایل‌ها واقعاً فایل روی دیسک نیستن؟

یکی از جالب‌ترین قسمت‌های ساختار فایل سیستم لینوکس اینه که همه چیزهایی که شبیه فایل می‌بینی، واقعاً مثل یه سند روی دیسک ذخیره نشدن. زیر /dev با گره‌های ویژه دستگاه‌ها سروکار داریم، /proc اطلاعات زنده فرایندها و هسته رو نشون می‌ده و /sys نمای ساخت‌یافته‌تری از بعضی اجزای کرنل ارائه می‌کنه. این‌ها برای شناخت سیستم خیلی مفیدن، ولی نباید باهاشون مثل فایل تمرین داخل خانه خودت رفتار کنی.

این مسیرهای ویژه برای مشاهده وضعیت سیستم ارزش دارن، ولی بعضی ورودی‌هاشون می‌تونن روی رفتار سیستم هم اثر بذارن. پس برای یادگیری ساختار فایل سیستم لینوکس لازم نیست در /proc/sys چیزی بنویسی یا گره‌های /dev رو دست‌کاری کنی. فعلاً فقط چند مسیر آشنا و عمومی رو مشاهده کن. هدف این درس اینه که بفهمی چرا یه مسیر «فایل‌مانند» ممکنه با فایل متنی عادی فرق داشته باشه، نه اینکه تنظیمات کرنل رو تغییر بدی.

head -n 3 /proc/version
ls -ld /proc /sys /dev
ls -l /dev/null

از این فرمان‌ها معمولاً می‌فهمی چه نوع هسته‌ای در حال اجراست و مسیرهای خاص سیستم چه شکلی دارن. مثلاً /dev/null نمونه معروفی از یک مقصد ویژه‌ست که داده نوشته‌شده در اون دور ریخته می‌شه. این مسیر یک فایل متنی معمولی نیست، پس نتیجه‌گیری درباره اندازه و محتوای اون نباید شبیه یک سند داخل خانه کاربر باشه. اگر خروجی در محیط آموزشی محدود بود، همون محدودیت رو ثبت کن.

پوشه‌های /boot، /opt، /srv، /mnt و /media به چه درد می‌خورن؟

حفظ کردن تک‌تک این مسیرها از روز اول لازم نیست. همین‌قدر بدونی /boot با فایل‌های راه‌اندازی سیستم ارتباط داره و نباید بی‌برنامه تغییرش بدی. وقتی بعدها در مستندات یه برنامه به /opt یا /srv برخوردی، می‌فهمی هر کدوم ممکنه چه نقشی داشته باشن. در آموزش فایل سیستم لینوکس دنبال این نیستیم که برای هر پوشه یک دستور حفظ کنی؛ می‌خوای بتونی نقش مسیر رو از روی نوع داده تشخیص بدی.

توی ساختار فایل سیستم لینوکس، /opt معمولاً برای بعضی نرم‌افزارهای افزوده در نظر گرفته می‌شه و /srv می‌تونه محل داده‌هایی باشه که یه سرویس ارائه می‌ده. ولی از اسم مسیر نباید نتیجه بگیری همه وب‌سرورها حتماً از /srv استفاده می‌کنن. ممکنه یه سرویس مسیر اختصاصی خودش رو داشته باشه. برای فهم مسیر واقعی باید تنظیمات همون برنامه رو بخونی، نه اینکه حدس بزنی هر سرویس کجا اطلاعاتش رو گذاشته.

مسیرهای /mnt و /media رو هم زیاد می‌بینی. معمولاً اولی برای اتصال‌های موقت یا مدیریتی و دومی برای رسانه‌های جداشدنی استفاده می‌شه. اما ساختن یه پوشه به اسم /mnt/disk یعنی یه آدرس ساخته‌ای، نه اینکه واقعاً یه دیسک رو Mount کرده باشی! برای تشخیص اتصال واقعی می‌تونی از findmnt استفاده کنی، اگه روی توزیعت نصب باشه. بحث پارتیشن و Mount رو در درس مدیریت دیسک LPIC-1 با جزئیات بیشتری دنبال می‌کنیم.

فایل سیستم لینوکس چیست و چه فرقی با پارتیشن و Mount داره؟

حالا تصور کن می‌خوای بفهمی چرا مسیر /var/log پر شده. از روی اسم پوشه نمی‌تونی بگی دقیقاً روی کدوم دیسک قرار گرفته. پوشه یه نقطه در درخت آدرس‌هاست، پارتیشن نوعی تقسیم‌بندی فضای ذخیره‌سازیه، فایل‌سیستم داده‌ها رو سازمان‌دهی می‌کنه و Mount اون فایل‌سیستم رو در یه نقطه از درخت در دسترس می‌ذاره. این تفاوت‌ها بخش مهمی از ساختار لینوکس هستن؛ قاطی‌کردنشون باعث می‌شه موقع عیب‌یابی دنبال علت اشتباه بگردی.

ممکنه /home روی یه دیسک جدا باشه و /var روی یه فایل‌سیستم دیگه، ولی هر دو در همون درخت واحد دیده می‌شن. این یکی از نکته‌های اصلی ساختار فایل سیستم لینوکس هست: آدرس فایل الزاماً محل فیزیکی ذخیره اون رو نشون نمی‌ده. وقتی یه بخش سیستم پر می‌شه، باید فایل‌سیستم میزبان همون مسیر رو بررسی کنی، نه اینکه فقط فضای «دیسک اصلی» رو از روی حدس حساب کنی.

df -h "$HOME" /tmp
if command -v findmnt >/dev/null 2>&1; then
  findmnt -T "$HOME"
else
  printf "findmnt در این محیط نصب نیست\n"
fi

در خروجی df احتمالاً ستون‌هایی مثل Filesystem، Size و Use% می‌بینی، ولی مقادیر و نام دستگاه‌ها کاملاً وابسته به محیطه. findmnt -T هم در صورت نصب بودن می‌تونه محل اتصال مؤثر برای مسیر انتخاب‌شده رو نشون بده. هیچ‌کدوم از این فرمان‌ها Mount جدیدی نمی‌سازن یا پارتیشن رو دست‌کاری نمی‌کنن. برای آموزش مقدماتی همین مشاهده خیلی ارزشمندتر از اجرای عجولانه دستورهای پارتیشن‌بندیه.

پرونده آموزشی: برنامه پشتیبان‌گیری چرا دیشب فایل جدید نساخته؟

برگردیم به همون پرونده اول مقاله: فایل پشتیبان دیشب تولید نشده و همه منتظرن یه نفر مشکل رو پیدا کنه. به جای اینکه فوری سرویس رو ری‌استارت کنی یا مجوز یه پوشه رو باز کنی، اول مسئله رو تکه‌تکه کن. ساختار فایل سیستم لینوکس اینجا مثل یه نقشه کمکت می‌کنه: تنظیمات احتمالاً یه جاست، گزارش اجرا جای دیگه و فایل خروجی ممکنه روی یه فایل‌سیستم جدا قرار گرفته باشه.

اول باید بدونیم برنامه مقصد پشتیبان رو از کجا می‌خونه؛ ممکنه فایلی در /etc باشه، ممکنه هم تنظیمات خودش رو جای دیگه نگه داره. بعد دنبال لاگ یا Journal می‌گردیم تا ببینیم اصلاً اجرا شده یا نه. در قدم بعدی، وضعیت پایدار برنامه و مسیر خروجی رو بررسی می‌کنیم. هنوز هیچ چیز ثابت نشده؛ این‌ها فقط فرضیه‌های اولیه بر اساس ساختار دایرکتوری لینوکس هستن. فرق عیب‌یابی خوب با حدس بی‌پایه همینه.

اگه مشخص شد برنامه اصلاً از /etc استفاده نمی‌کنه، باید سراغ مستندات همون برنامه بری. اگه لاگش در Journal ذخیره می‌شه، گشتن دنبال یه فایل ثابت در /var/log وقت تلف کردنه. حتی ممکنه فایل پشتیبان روی مقصد شبکه یا فضای ابری ذخیره بشه. پس این درس نمی‌گه «همیشه فلان مسیر رو باز کن»؛ می‌گه ساختار فایل سیستم لینوکس رو مثل قطب‌نما استفاده کن و بعد شواهد واقعی سیستم رو بررسی کن.

تمرین عملی اول: شناسایی مسیرهای واقعی روی لینوکس خودت

اینجا یه تمرین فقط‌خواندنی داریم. با Ubuntu، Debian یا هر محیط لینوکسی دیگه‌ای می‌تونی ببینی کدوم پوشه‌های مهم وجود دارن و /bin به کجا اشاره می‌کنه. اگه یه پوشه نبود، قرار نیست برای شبیه شدن به مقاله بسازیش. هدف آموزش ساختار فایل سیستم لینوکس اینه که تفاوت محیط‌ها رو ثبت کنی و از روی مشاهده حرف بزنی. برای این کار هم نیازی به sudo نداری.

printf "HOME: %s\n" "$HOME"
for path in / /etc /home /usr /var /var/log /tmp /run /proc /sys /dev; do
  if [ -d "$path" ]; then
    printf "FOUND  %s\n" "$path"
  else
    printf "ABSENT %s\n" "$path"
  fi
done
printf "\n/bin resolves to: "
readlink -f /bin

این خروجی بهت نشون می‌ده کدوم مسیرها در محیط فعلی واقعاً وجود دارن و /bin در نهایت به کجا اشاره می‌کنه. اگر دوست داشتی نتیجه رو با یک ماشین مجازی دیگر مقایسه کن، اما به اختلاف‌ها برچسب «خراب» یا «غیراستاندارد» نزن. ممکنه توزیع، محیط اجرا یا ابزارهای نصب‌شده متفاوت باشن. هدف این تمرین دقیقاً همین مشاهده و مستندسازی تفاوت‌هاست.

تمرین عملی دوم: ساختار دایرکتوری لینوکس رو توی یه پروژه کوچک بساز

حالا یه آزمایش داریم که خودت می‌تونی بدون ریسک انجامش بدی. به جای ساختن فایل واقعی داخل /etc یا /var، توی پوشه خانگی خودمون یه برنامه خیالی می‌سازیم. چهار بخش براش می‌ذاریم: تنظیمات، داده پایدار، گزارش اجرا و فایل موقت. این دقیقاً همون منطق تفکیک داده در خیلی از برنامه‌هاست؛ فقط همه چیز داخل محیط تمرینی nb-filesystem-lab می‌مونه و برای انجامش دسترسی مدیر لازم نیست.

فرض کن برنامه فرضی ما هر روز چند فایل رو بررسی می‌کنه. آدرس مقصد پشتیبان باید در بخش config باشه، وضعیت آخرین اجرای موفق رو در state نگه می‌داریم، اتفاقات هر اجرا رو در logs می‌نویسیم و فایل میانی به temp می‌ره. وقتی این چهار نقش رو از هم جدا می‌کنی، هم عیب‌یابی ساده‌تر می‌شه، هم می‌فهمی چرا ساختار پوشه‌های لینوکس صرفاً چند اسم تصادفی نیست.

LAB="$HOME/nb-filesystem-lab"
mkdir -p "$LAB/config" "$LAB/state" "$LAB/logs" "$LAB/temp"
printf "backup_target=archive-local\n" > "$LAB/config/backup.conf"
printf "last_success=2026-10-11\nfiles_checked=4\n" > "$LAB/state/status.txt"
printf "INFO: read backup.conf\nINFO: checked 4 files\n" > "$LAB/logs/backup.log"
printf "work-in-progress\n" > "$LAB/temp/session.txt"
printf "\nساختار آزمایش:\n"
find "$LAB" -maxdepth 2 -type f -print | sort

دقت کن این فرمان‌ها با > فایل‌های نمونه رو می‌نویسن؛ یعنی اگه همین پوشه از قبل وجود داشته باشه، احتمال بازنویسی فایل‌های همنام هست. پس قبل از اجرا مطمئن شو nb-filesystem-lab یه محیط تمرینی خالیه، وگرنه یه نام تازه انتخاب کن. تاریخ و اسم‌های داخل فایل‌ها هم ساختگی‌ان. داریم رفتار فایل‌ها رو یاد می‌گیریم، نه اینکه گزارشی از یه سیستم واقعی ثبت کنیم.

LAB="$HOME/nb-filesystem-lab"
printf "%s\n" "--- تنظیمات ---"
cat "$LAB/config/backup.conf"
printf "%s\n" "--- وضعیت پایدار ---"
cat "$LAB/state/status.txt"
printf "%s\n" "--- گزارش اجرا ---"
grep -n "INFO" "$LAB/logs/backup.log"
printf "%s\n" "--- فایل موقت ---"
cat "$LAB/temp/session.txt"

حالا خروجی رو نگاه کن. اگه دنبال مقصد پشتیبان باشی باید config/backup.conf رو بخونی؛ اگه آخرین وضعیت ثبت‌شده رو می‌خوای، سراغ state/status.txt می‌ری. برای دیدن رویدادهای ثبت‌شده هم logs/backup.log منطقی‌تره. می‌بینی؟ ساختار فایل سیستم لینوکس دقیقاً کمک می‌کنه بدون گشتن بی‌هدف، برای هر سؤال به یه نوع داده مشخص برسی.

نتیجه واقعی آزمایش؛ تفاوت تنظیمات، داده و لاگ را ببین

در نمونه نمایشی پایین، مقدار backup_target=archive-local از فایل تنظیمات خونده می‌شه، وضعیت دو خط داره و گزارش هم دو پیام INFO نشون می‌ده. این‌ها خروجی همین داده‌های ساختگی هستن و آدرس کامل پوشه بسته به HOME دستگاه تو فرق می‌کنه. مهم‌تر از ظاهر خروجی اینه که بتونی توضیح بدی هر خط از کدوم فایل اومده؛ این توضیح نشون می‌ده واقعاً منطق فایل‌ها رو فهمیدی.

--- تنظیمات ---
backup_target=archive-local
--- وضعیت پایدار ---
last_success=2026-10-11
files_checked=4
--- گزارش اجرا ---
1:INFO: read backup.conf
2:INFO: checked 4 files
--- فایل موقت ---
work-in-progress

یه سؤال ازت دارم: اگه فردا محتوای temp پاک بشه، آیا هنوز می‌تونی آخرین وضعیت ثبت‌شده رو از state بخونی؟ توی همین مثال بله؛ چون اطلاعات رو جدا نگه داشتیم. اما برعکسش رو نمی‌شه تضمین کرد: داشتن لاگ همیشه به معنی امکان بازسازی تمام داده‌های پایدار نیست. این تفاوت ساده بعدها وقتی بحث بکاپ و نگهداری سرویس پیش میاد، خیلی مهم می‌شه.

۵ اشتباه رایج در شناخت ساختار پوشه‌های لینوکس

اشتباه اول: فکر کنیم /usr همان خانه کاربران است

یه اشتباه مشهور اینه که فکر کنیم /usr چون شبیه User نوشته شده، خونه کاربراست. اما توی ساختار فایل سیستم لینوکس، فایل‌های شخصی معمولاً در /home یا مسیر خانگی همون حساب هستن و /usr بیشتر به منابع نرم‌افزارهای نصب‌شده مربوط می‌شه. برای ساخت فایل تمرینی به جای تغییر دادن پوشه‌های سیستمی، از $HOME استفاده کن. همین انتخاب کوچیک جلوی خیلی از دردسرهای دسترسی رو می‌گیره.

اشتباه دوم: تصور کنیم همه محتویات /var پاک‌شدنی‌اند

اسم /var از Variable میاد، نه از «فایل‌های بی‌اهمیت». این پوشه می‌تونه شامل داده واقعی سرویس، صف درخواست‌های انجام‌نشده و گزارش‌های لازم برای عیب‌یابی باشه. پس وقتی دیسک پر شد، پاک کردن بی‌فکر محتویاتش راه‌حل نیست. اول بفهم هر بخش متعلق به کدوم برنامه‌ست و آیا حذفش برگشت‌پذیره یا نه. اگه مسیر درست رو ندونی، یه خطای کمبود فضا رو راحت به خرابی داده تبدیل می‌کنی.

اشتباه سوم: یکی گرفتن /tmp با فضای ذخیره همیشگی

از فایل موقت نباید انتظار نگهداری همیشگی داشته باشی. حتی اگه امروز چیزی در /tmp ساختی و فردا هنوز بود، این نتیجه رو به همه نصب‌های لینوکس تعمیم نده. ساختار فایل سیستم لینوکس فقط نقش معمول مسیر رو مشخص می‌کنه؛ سیاست پاک‌سازی و شیوه پیاده‌سازی روی دوام واقعی داده اثر دارن. پس برای اطلاعاتی که باید بمونه، محل مناسب و نسخه پشتیبان قابل بازیابی در نظر بگیر.

اشتباه چهارم: فرض کنیم هر مسیر یک دیسک یا پارتیشن جداست

یکی از سوءبرداشت‌ها اینه که هر پوشه مهم حتماً پارتیشن جدا داره. ممکنه /home و /var هر دو روی یه فایل‌سیستم باشن، یا هرکدوم روی دستگاه جدا قرار گرفته باشن. از روی اسم پوشه نمی‌شه تشخیص داد. وقتی ساختار فایل سیستم لینوکس رو می‌شناسی، قدم بعدی مشاهده وضعیت Mount و فضای میزبان مسیره. اینطوری اگر جایی پر شد، دنبال دیسک درست می‌گردی و بی‌دلیل فایل‌های بخش دیگه رو پاک نمی‌کنی.

اشتباه پنجم: فکر کنیم هر فرمانی در /bin دوبار نصب شده

در توزیع‌های مجهز به طرح merged-/usr ممکنه /bin به /usr/bin اشاره کنه. بنابراین دیدن دو مسیر، اثبات وجود دو نسخه برنامه نیست. برای بررسی واقعی از readlink و command -v استفاده کن. اگر نتیجه در یک کانتینر یا توزیع دیگر متفاوت بود، اول معماری همون محیط رو بشناس و بعد قضاوت کن.

اگر دنبال یک فایل گم‌شده یا خطای سرویس بودی، از کجا شروع کنی؟

وقتی دنبال یه فایل گمشده یا دلیل خطای سرویس می‌گردی، قبل از تایپ دستور بپرس دقیقاً دنبال چی هستی. اگه موضوع تنظیماته، مستندات برنامه و مسیرهای متداول مثل /etc رو ببین. اگه داده شخصیه، از HOME شروع کن. اگه لاگ یا وضعیت برنامه رو می‌خوای، ابزار ثبت رخداد و مسیرهای مرتبط رو بررسی کن. این روش، هم برای آموزش لینوکس از صفر کاربرد داره و هم بعدها توی مدیریت سرور.

یه مثال دیگه بزنیم: مدیر می‌گه «برنامه نصب شده ولی فرمانش پیدا نمی‌شه». اینجا ساختار فایل سیستم لینوکس فقط نقطه شروعه. اول با command -v بررسی کن شل فرمان رو پیدا می‌کنه یا نه، بعد متغیر PATH و روش نصب رو ببین. برای خطای سرویس هم همین‌طوره؛ شاید لاگ در فایل باشه و شاید در Journal. پس به‌جای جست‌وجوی کل دیسک، سؤال رو دقیق‌تر کن و سراغ ابزار مناسب همون مسئله برو.

تمرین مستقل: خودت نقش‌های یک برنامه را از هم جدا کن

این بار می‌خوام بدون کپی‌کردن جواب آماده، یه ساختار کوچک طراحی کنی. فرض کن یه برنامه برای امانت‌دادن کتاب داری. داخل پوشه خانگی خودت چهار محل براش بساز: یکی برای تنظیم سقف امانت، یکی برای ثبت آخرین شماره، یکی برای گزارش اتفاقات و یکی برای اطلاعات موقتی. لازم نیست این برنامه واقعاً اجرا بشه؛ هدف اینه که بتونی نقش هر پوشه رو توضیح بدی و منطق پشت ساختار فایل سیستم لینوکس رو با یه نمونه جدید به کار ببری.

حالا برای پروژه امانت کتاب یه خطای فرضی بساز: برنامه شماره آخرین امانت رو اشتباه نشون می‌ده. اولین حدست باید مسیر داده وضعیت باشه، نه اینکه فوراً فایل تنظیمات رو تغییر بدی. اگر خود اجرا خطا داشت، بخش گزارش می‌تونه سرنخ بده؛ اگر سقف امانت غلط بود، تنظیمات رو بررسی کن. این تمرین کوچیک نشون می‌ده فهم ساختار فایل سیستم لینوکس یعنی هر نوع داده رو از هم تشخیص بدی و به‌جای حدس، ترتیب بررسی منطقی داشته باشی.

اگه بعداً بری سراغ LPIC-1، سرور، DevOps یا امنیت، همین مدل فکر کردن خیلی به کارت میاد. وقتی می‌فهمی یه فایل «تنظیمات»ه یا «داده پایدار»، دیگه برای هر خطا اولین واکنشت تغییر مجوز یا حذف فایل نیست. البته این درس هنوز قرار نیست جای آموزش مدیریت پارتیشن یا دسترسی‌ها رو بگیره؛ برای اون‌ها باید سراغ تمرین‌های تخصصی‌تر بری و اول اثر هر فرمان رو بفهمی.

ارتباط این درس با مراحل بعدی Linux Essentials و LPIC-1

تا اینجا از مسیر رایگان Linux Essentials نابغه‌ها چند قدم برداشتیم: اول در «لینوکس چیست؟» با سیستم‌عامل و توزیع آشنا شدی، بعد در درس ترمینال و Bash کار با خط فرمان رو شروع کردی و در درس دستورات لینوکس سراغ فایل‌ها رفتی. حالا با ساختار دایرکتوری لینوکس می‌دونی خیلی از اون فایل‌ها چرا در مسیرهای متفاوتی دیده می‌شن. گام بعدی، فهم مالکیت و دسترسی فایل‌هاست.

برای ادامه همین مسیر، درس مجوز فایل در لینوکس، chmod و chown رو بخون؛ اونجا می‌فهمی چرا دیدن فایل و اجازه تغییر دادنش دو موضوع جدا هستن. اگه دوست داری مبانی رو منظم‌تر با ویدیو و تمرین یاد بگیری، پکیج کامل Linux Essentials نابغه‌ها هم در دسترسه. عجله‌ای برای خرید نیست؛ اول مطمئن شو موضوعات رایگان رو فهمیدی و تمرین‌ها رو واقعاً انجام دادی.

سؤالات متداول درباره ساختار فایل سیستم لینوکس

منابع فنی و مسیر مطالعه بیشتر

برای اینکه فقط به توضیح من تکیه نکنی، می‌تونی نقش مسیرها رو در استاندارد رسمی Filesystem Hierarchy Standard و راهنمای hier(7) بررسی کنی. برای تفاوت ساختار قدیمی و merged-/usr، مستندات Debian مفیده و جزئیات /var/tmp در بخش /var استاندارد FHS توضیح داده شده. این منابع برای بررسی فنی‌ان؛ تمرین و روایت آموزشی این صفحه مخصوص نابغه‌هاست.

حالا اگه کسی بپرسه «ساختار فایل سیستم لینوکس چیست؟»، می‌تونی بیشتر از یه فهرست حفظی جواب بدی. می‌دونی /etc معمولاً برای چیه، چرا هرچیزی در /var پاک‌کردنی نیست، تفاوت /root و /home کجاست و چرا ممکنه دو مسیر روی دو دیسک جدا قرار بگیرن. مهم‌تر از همه، یاد گرفتی قبل از تغییر دادن فایل‌ها سؤال درست بپرسی. از اینجا به بعد هر بار یه مسیر جدید دیدی، به جای ترسیدن، نقش اون رو پیدا کن.