4.3. مسیر انبار و پوشه انبار

مدل‌های داده‌ی شیء انبار و شیء سیستم‌فایل در Nix مینیمال و انتزاعی هستند. اما برای اینکه اشیاء انبار واقعاً توسط نرم‌افزار مورد استفاده قرار گیرند، باید از طریق سیستم‌فایل سیستم‌عامل در دسترس قرار گیرند.

این کار با قرار دادن تمام اشیاء انبار در یک پوشه انبار واحد انجام می‌شود. هر ورودی در آن پوشه، یک نام پایه مسیر انبار است که به یک شیء انبار اشاره می‌کند. اشیاء انبار ارائه‌شده به این روش را می‌توان از طریق مسیرهای انبار ارجاع داد.

نام پایه مسیر انبار

Nix ارجاعات به اشیاء انبار را به عنوان نام‌های پایه مسیر انبار پیاده‌سازی می‌کند.

نام پایه مسیر انبار را به عنوان یک [شناسه یکتا]ی مبهم (opaque) در نظر بگیرید: تنها راه به‌دست آوردن نام پایه مسیر انبار، اضافه کردن یا ساختن اشیاء انبار است. یک نام پایه مسیر انبار همیشه دقیقاً به یک شیء انبار اشاره خواهد کرد.

نام‌های پایه مسیر انبار جفت‌هایی هستند از:

یک [خلاصه (digest)] بیست بایتی برای شناسایی
یک [نام] نمادین برای خواندن توسط انسان

مثال

خلاصه (Digest): q06x3jll2yfzckz2bzqak089p43ixkkq

نام (Name): firefox-33.1

یک نام پایه مسیر انبار به عنوان ترکیب (Concatenation) موارد زیر به یک رشته تبدیل می‌شود:

خلاصه ارائه شده در Nix32، که گونه‌ای از Base32 است (۲۰ بایت هش به ۳۲ کاراکتر ASCII تبدیل می‌شوند)
خط تیره (-)
نام

مثال

q06x3jll2yfzckz2bzqak089p43ixkkq-firefox-33.1
|------------------------------| |----------|
              digest                 name

اینکه دقیقاً چگونه هش محاسبه می‌شود، به نوع شیء انبار (store object) مورد ارجاع بستگی دارد. هش‌های مسیر انبار قرار است مبهم باشند، بنابراین برای بیشتر عملیات‌ها، نیازی به دانستن جزئیات نیست. با این حال، راهنما دارای یک مشخصات کامل از هش‌های مسیر انبار است.

مسیر پوشه انبار

هر انبار نیکس (Nix store) دارای یک مسیر پوشه انبار است. این یک مسیر مطلق و از نظر واژگانی متعارف (بدون شامل بودن هیچ‌گونه ..، . یا موارد مشابه) است که به پوشه‌ای اشاره می‌کند که تمام اشیاء انبار در آنجا یافت می‌شوند.

نکته

پوشه انبار به طور پیش‌فرض /nix/store است، اما در اصل می‌تواند دلخواه باشد.

مسیر انبار

یک مسیر انبار، جفتی از یک مسیر پوشه انبار و یک [نام پایه مسیر انبار] است. این مسیر به عنوان الحاق موارد زیر به یک مسیر سیستم‌فایل تبدیل می‌شود:

[مسیر پوشه انبار] (معمولاً /nix/store)
جداکننده مسیر (/)
[نام پایه مسیر انبار]

مثال

  /nix/store/q06x3jll2yfzckz2bzqak089p43ixkkq-firefox-33.1
  |--------| |------------------------------| |----------|
store directory            digest                 name

هنگامی که یک انبار مشخص، یا یک مسیر پوشه انبار مشخص (که تمام انبارهای در حال استفاده در آن اشتراک دارند) را ثابت کرده‌ایم، نحو انتزاعی مسیرهای انبار و نحو انتزاعی نام‌های پایه مسیر انبار با یکدیگر منطبق می‌شوند: مسیر پوشه انبار از طریق زمینه (Context) شناخته می‌شود، بنابراین از یک مسیر انبار تا مسیر بعدی، تنها آن دو فیلد دیگر تغییر می‌کنند.

نمایش اشیاء انبار در سیستم‌فایل‌های سیستم‌عامل

همه انبارها از طریق سیستم‌فایل قابل دسترسی نیستند. اما اگر انبار دارای یک بازنمایی در سیستم‌فایل باشد، موارد زیر باید برقرار باشند:

مسیر پوشه انبار استاندارد (canonical) است: هیچ پیشوندی از مسیر (یعنی مسیر اولین بخش‌های n‌ام مسیر) به یک پیوند نمادین (symlink) اشاره نمی‌کند. به عبارت دیگر، پوشه انبار را می‌توان از روی مسیر پوشه انبار بدون دنبال کردن هیچ‌گونه پیوند نمادینی جستجو کرد. (این شرط یک شرط جداگانه علاوه بر «استاندارد بودن واژگانی» (lexical canonicity) است که در بالا توضیح داده شد و صرفاً ویژگی خودِ مسیر است. این «استاندارد بودن» (معمولی) ویژگی‌ای است که درباره مسیر و سیستم‌فایلی که در آن ناوبری می‌کند به طور مشترک وجود دارد.)

نکته

تنظیمات allow-symlinked-store را می‌توان برای تسهیل این الزامات به کار برد.
مسیر پوشه انبار در واقع به یک پوشه اشاره می‌کند.
پوشه انبار شامل، برای هر شیء انبار موجود در انبار، [شیء سیستم‌فایل] آن شیء انبار در [نام پایه مسیر انبار] (رندرشده) است. مجوزها و سایر فراداده‌های این فایل‌ها در پوشه انبار، در قالب نرمالی قرار دارند که در بخش نمایش در سیستم‌فایل‌های سیستم‌عامل توضیح داده شده است.

ویژگی‌های بالا به این معنا هستند که دسترسی‌های فایل زیر کار خواهند کرد. فرض کنید انباری طبق قوانین بالا روی سیستم‌فایل در دسترس داریم، و b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1 نام پایه مسیر انبارِ یک شیء انبار در آن انبار است.

فرض کنید که مسیر پوشه انبار /foo/bar است. در این صورت، /foo/bar/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1 وجود دارد و شیء سیستم‌فایلِ آن شیء انبار است.
فرض کنید مسیر پوشه انبار را نمی‌دانیم، اما قابلیت storeDir را برای پوشه انبار روی سیستم‌فایل داریم. (این مورد در یونیکس یک «توصیف‌گر فایل» (file descriptor) یا در ویندوز یک «دستگیره فایل» (file handle) خواهد بود.) در این صورت (با استفاده از علامت‌گذاری یونیکس برای این کار):

  openat(storeDir, "b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1", O_NOFOLLOW)

موفقیت‌آمیز خواهد بود (به شرطی که شیء سیستم‌فایل یک پیوند نمادین نباشد)، و قابلیت تولیدشده به شیء سیستم‌فایل آن شیء انبار اشاره خواهد کرد.

(رفتار مربوط به پیوندهای نمادین به دلیل محدودیت‌های POSIX دشوارتر مشخص می‌شود.)

جابه‌جایی اشیاء انبار

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

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

شما تنها در صورتی می‌توانید اشیاء انبار را به یک انبار دیگر کپی کنید که:

پوشه‌های انبارهای مبدأ و مقصد با یکدیگر مطابقت داشته باشند

یا
شیء انبار مورد نظر هیچ ارجاعی نداشته باشد، یعنی حاوی هیچ مسیر انباری نباشد

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

nix.dev/manual/nix/stable/store/store-path.html