خبر و ترفند روز

خبر و ترفند های روز را اینجا بخوانید!

ویندوز هنوز هم اجازه نمی‌دهد از این نام برای پوشه استفاده کنید — و دلیلش DOS است

Windows هنوز هم اجازه نمی‌دهد از این نام برای پوشه استفاده کنید — و دلیلش DOS است
سه حرف بی‌آزار را تایپ کردم و ویندوز طوری واکنش نشان داد که انگار به اجدادش توهین کرده‌ام.

این را امتحان کنید: روی دسکتاپ خود راست‌کلیک کنید، یک پوشه جدید بسازید و سعی کنید نام آن را CON بگذارید. ویندوز این کار را با خطایی رد می‌کند که می‌گوید نام دستگاه مشخص‌شده نامعتبر است و سپس نام New folder را بازمی‌گرداند؛ گویی اصلاً چیزی تایپ نکرده‌اید، درست است؟

حالا PRN، AUX، NUL، LPT1 یا COM3 را امتحان کنید؛ نتیجه قطعاً همان خواهد بود. حدود دو جین نام به‌ظاهر عادی همچنان برای فایل‌ها یا پوشه‌ها در ویندوز قابل استفاده نیستند. هرکدام از آن‌ها عملاً یک نشانی قدیمی‌اند که زمانی به قطعه‌ای سخت‌افزاری اشاره می‌کرد.

در سال ۱۹۸۱، نام فایل‌ها و دستگاه‌های سخت‌افزاری در یک فضای نام مشترک با یکدیگر رقابت می‌کردند. ویندوز هرگز آن نشانی‌های قدیمی را از رده خارج نکرده است.

ویندوز فهرستی مسدودشده شامل حدود دو جین واژه دارد

CON فقط مشهورترین مورد است

مستندات نام‌گذاری فایل Microsoft، نام‌های اصلی رزروشده برای دستگاه‌ها را CON، PRN، AUX، NUL، از COM1 تا COM9 و از LPT1 تا LPT9 اعلام می‌کند. این ۲۲ نام پایه را نمی‌توان برای فایل‌ها و پوشه‌های عادی به کار برد. ویندوز همچنین شش گونه کمتر شناخته‌شده با اعداد بالانویس، از جمله COM¹ و LPT³، را رزرو کرده است.

فهرست نام‌های فایل رزروشده در Windows

هر شناسه زمانی به یک دستگاه فیزیکی یا منطقی اشاره می‌کرد. CON به کنسول اشاره دارد که ورودی صفحه‌کلید و خروجی صفحه‌نمایش را منتقل می‌کند. PRN نمایانگر چاپگر پیش‌فرض است، درحالی‌که AUX یک دستگاه سریال کمکی را مشخص می‌کند. NUL دستگاه تهی است؛ سطل زباله‌ای دیجیتال که داده‌ها را می‌پذیرد و بی‌هیچ اعتراضی دور می‌ریزد. نام‌های COM به درگاه‌های ارتباط سریال تعلق دارند، درحالی‌که نام‌های LPT درگاه‌های موازی چاپگر را مشخص می‌کنند که دهه‌ها پیش از بیشتر رایانه‌های شخصی مصرفی ناپدید شدند.

DOS پیش از آنکه پوشه‌ها وجود داشته باشند، سخت‌افزار را شبیه فایل‌ها جلوه داد

میراث CP/M که در سال ۱۹۸۱ عرضه شد

جعبه‌های IBM PC-DOS

وقتی DOS ۱.۰ در اوت ۱۹۸۱ همراه با IBM PC عرضه شد، از نسخه‌ای اولیه از FAT، یکی از سیستم‌فایل‌هایی که ویندوز هنوز از آن پشتیبانی می‌کند، استفاده می‌کرد و هیچ پشتیبانی‌ای از دایرکتوری‌ها نداشت. هر دیسک شامل یک فهرست تخت و واحد از فایل‌ها بود و هیچ پوشه یا ساختار سلسله‌مراتبی برای جداسازی آن‌ها وجود نداشت.

DOS همچنین به روشی یکپارچه نیاز داشت تا نرم‌افزارها بتوانند داده‌ها را به سخت‌افزارهایی مانند چاپگرها و درگاه‌های سریال ارسال کنند. CP/M شرکت Digital Research که تأثیر زیادی بر DOS گذاشته بود، پیش‌تر الگویی هوشمندانه ارائه کرده بود. سیستم‌عامل می‌توانست سخت‌افزار را از طریق نام‌هایی در دسترس قرار دهد که برنامه‌ها قادر بودند آن‌ها را، درست مانند فایل‌های عادی، باز و استفاده کنند.

مطلب مرتبط:   چگونه یک GPU مطلوب برای برنامه‌ها در ویندوز 10 انتخاب کنیم

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

این ایده به مدل فایل دستگاهی مورد استفاده در Unix شباهت داشت و به همین دلیل است که امروزه نیز هدایت خروجی با > NUL در یک اسکریپت دسته‌ای ویندوز کار می‌کند. DOS با فراهم‌کردن امکان دسترسی برنامه‌ها به فایل‌ها و دستگاه‌ها از طریق عملیات مشابه، نیاز به پیاده‌سازی فرمان‌های جداگانه مدیریت سخت‌افزار در هر برنامه را از میان برداشت. کاربران نخستین رایانه‌های شخصی حتی می‌توانستند با وارد کردن فرمانی مانند COPY CON NOTES.TXT، تایپ محتوای فایل در کنسول و فشردن Ctrl+Z برای ذخیره‌سازی آن، یک فایل متنی ایجاد کنند.

مشکل این بود که DOS این نام‌های دستگاه را به مکان اختصاصی مشخصی محدود نکرد. Unix فایل‌های دستگاه را در دایرکتوری /dev قرار می‌داد، درحالی‌که DOS شناسه‌های سخت‌افزاری خود را هرجا که امکان درج نام فایل وجود داشت، تشخیص می‌داد. از آن زمان تاکنون، فایل‌ها و دستگاه‌ها برای استفاده از این نام‌ها با یکدیگر رقابت کرده‌اند.

دایرکتوری‌ها در سال ۱۹۸۳ از راه رسیدند و این نام‌ها را با خود به تک‌تک آن‌ها بردند

PRN باید از همه‌جا کار می‌کرد، بنابراین همه‌جا کار می‌کند

رایانه شخصی اولیه IBM

DOS ۲.۰ در مارس ۱۹۸۳ همراه با IBM PC XT عرضه شد و دایرکتوری‌های سلسله‌مراتبی را معرفی کرد. کاربران و توسعه‌دهندگان سرانجام توانستند به‌جای اتکا به یک فهرست تخت و واحد، فایل‌ها را درون پوشه‌ها سازمان‌دهی کنند.

این بهبود مشکلی در زمینه سازگاری با نسخه‌های پیشین ایجاد کرد. برنامه‌های موجود DOS از قبل انتظار داشتند نام‌هایی مانند PRN در هر محلی که استفاده می‌شوند، به مقصد خود ارجاع داده شوند. تغییر این رفتار پس از معرفی دایرکتوری‌ها می‌توانست برنامه‌هایی را که برای سیستم‌عامل قبلی نوشته شده بودند، از کار بیندازد.

خط فرمان MS-DOS که محتویات پوشه را نشان می‌دهد

Microsoft این رفتار را با آموزش تجزیه‌گر مسیر برای شناسایی نام‌های رزروشده دستگاه‌ها در تمام دایرکتوری‌ها حفظ کرد. DOS به‌جای قراردادن آن‌ها در یک مکان سیستمی اختصاصی مشابه دایرکتوری /dev در Unix، آن‌ها را سراسری کرد. در نتیجه، مسیری مانند C:\Users\You\Documents\PRN به یک فایل یا پوشه عادی با نام PRN اشاره نمی‌کند. سیستم‌عامل همچنان آن را به‌عنوان دستگاه چاپگر تفسیر می‌کند.

می‌توانید تله‌ای را که این وضعیت ایجاد می‌کند ببینید. وقتی نامی در همه‌جا به یک دستگاه ارجاع داده می‌شود، دیگر هیچ‌جا نمی‌تواند نام فایل باشد.

مطلب مرتبط:   چگونه درایورهای خراب ویندوز 10 را رفع کنیم

پسوند نجاتتان نمی‌دهد

CON.txt همچنان کنسول است

Windows PowerShell که پیام خطای git clone را نشان می‌دهد

این مشکل اغلب گریبان توسعه‌دهندگانی را می‌گیرد که با سیستم‌عامل‌های مختلف کار می‌کنند، زیرا Windows با نام‌های رزروشدهٔ دستگاه‌ها رفتاری متفاوت از نام فایل‌های عادی دارد. قواعد مدیریت مسیر آن، پیش از در نظر گرفتن پسوند، نام پایه را با فهرست دستگاه‌های سیستم تطبیق می‌دهند. بنابراین، افزودن پسوند نام را معتبر نمی‌کند. CON.txt همچنان به‌عنوان کنسول تفسیر می‌شود، NUL.mp3 همچنان به دستگاه تهی اشاره می‌کند و AUX.c همچنان دستگاه کمکی رزروشده تلقی می‌شود.

همین میراث DOS همچنین توضیح می‌دهد که چرا بسیاری از پسوندهای فایل در Windows هنوز سه‌حرفی هستند.

این صرفاً یک نکتهٔ تاریخی جالب نیست، بلکه همچنان مانعی عملی در توسعهٔ نرم‌افزار چندسکویی است. Linux و macOS فایل‌های دستگاه را در پوشهٔ /dev محصور می‌کنند؛ بنابراین، توسعه‌دهندگان این سیستم‌ها می‌توانند بدون مشکل فایل‌هایی با نام aux.c یا nul.h ایجاد و commit کنند.

مشکلات زمانی آغاز می‌شوند که کسی بخواهد همان مخزن را در یک درخت کاری عادی Windows clone یا check out کند. Win32 API نام رزروشده را رد می‌کند، مانع از ایجاد فایل روی دیسک به‌وسیلهٔ Git می‌شود و عملیات را با شکست مواجه می‌کند. هیچ تنظیم معمولی Git نمی‌تواند چنین نام فایلی را برای Windows قابل‌حمل کند؛ بنابراین، تغییر نام آن در مخزن همچنان راه‌حل مطمئن چندسکویی است.

NTFS با آن مشکلی ندارد؛ این Windows است که مخالفت می‌کند

پوشه‌ای که می‌توانید ایجاد کنید، اما سپس نمی‌توانید حذفش کنید

خط فرمان Windows در حال اجرای فرمان نمایش محتویات پوشه

نکتهٔ غافلگیرکننده اینجاست: وقتی نام از طریق یک مسیر توسعه‌یافته ارائه شود که تجزیهٔ عادی Win32 را دور می‌زند، NTFS می‌تواند فایل یا پوشه‌ای با نام CON (یا هر نام رزروشدهٔ دیگری) ذخیره کند. محدودیت در سطح بالاتری از پشتهٔ نرم‌افزار، یعنی در لایهٔ مدیریت مسیر که نام‌های ارائه‌شده از سوی برنامه‌ها را به فضای نام داخلی مورد استفادهٔ Windows تبدیل می‌کند، اعمال می‌شود. قواعد قدیمی نام دستگاه‌ها معمولاً در همان‌جا اجرا می‌شوند.

بنابراین، دور زدن عادی‌سازی معمول مسیر می‌تواند این محدودیت را از میان بردارد. در Command Prompt می‌توانید دستور زیر را اجرا کنید:

mkdir \\?\C:\Users\You\Desktop\con

پیشوند \\?\ تجزیهٔ عادی مسیر در Win32 را غیرفعال می‌کند و ادامهٔ مسیر را مستقیم‌تر به سیستم فایل می‌فرستد. سپس پوشه روی دیسک نوشته می‌شود و روی دسکتاپ ظاهر می‌شود.

کاوشگر فایل Windows که پوشه‌ای با نام con را نشان می‌دهد

ایجاد آن از استفاده کردنش آسان‌تر است. File Explorer ممکن است پوشه را نمایش دهد، اما نتواند آن را باز کند، تغییر نام دهد یا حذف کند، زیرا رابط همچنان به مدیریت عادی مسیر در Win32 متکی است و با همان تعارض نام رزروشده مواجه می‌شود.

مطلب مرتبط:   13 روش برای باز کردن تنظیمات سیستم ویندوز

برای حذف پوشه باید دوباره از مسیر تحت‌اللفظی استفاده کرد:

rmdir \\?\C:\Users\You\Desktop\con
خط فرمان Windows در حال اجرای فرمان‌های پوشه

این تفاوت محل محدودیت را مشخص می‌کند: NTFS نام را ذخیره می‌کند، در حالی که لایهٔ عادی مسیر در Windows از مدیریت آن سر باز می‌زند.

سال‌ها یک مسیر دستگاه با ساختار نادرست می‌توانست Windows را از کار بیندازد

C:\CON\CON
صفحه آبی مرگ Windows حاوی خطای مهلک

این نام‌های رزروشدهٔ دستگاه‌ها مشکلاتی بسیار فراتر از دشواری نام‌گذاری فایل‌ها ایجاد کردند و نقص CON/CON همچنان یکی از بدنام‌ترین باگ‌های Windows ۹۸ است که ارزش مرور دوباره دارد. در Windows ۹۵، Windows ۹۸ و Windows ۹۸ Second Edition، ارجاع به یک دستگاه از طریق مسیری تودرتو و نادرست مانند C:\CON\CON یا C:\AUX\AUX می‌توانست سیستم‌عامل را از کار بیندازد یا قفل کند.

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

Microsoft در ۱۶ مارس ۲۰۰۰ از طریق بولتن امنیتی MS00-۰۱۷ این آسیب‌پذیری را برطرف کرد. وصله، بررسیِ مفقود برای مسیرهای حاوی چندین نام دستگاه DOS را اصلاح کرد و مانع از آن شد که Windows دسترسی غیرمجاز به منبع را که موجب از کار افتادن سیستم می‌شد امتحان کند. این وصله سامانهٔ زیربنایی نام دستگاه‌ها را حذف نکرد، زیرا آن سازوکار همچنان با چندین دهه سازگاری نرم‌افزاری درهم‌تنیده بود.

تابلوی اتصال هنوز به برق وصل است

پس چرا Microsoft این فهرست را به‌سادگی حذف نمی‌کند؟ پاسخ، سازگاری با گذشته در سخت‌افزار و نرم‌افزار است. دهه‌هاست که اسکریپت‌ها و برنامه‌ها فایل‌هایی با نام NUL، CON، COM1 و LPT1 را باز می‌کنند و Windows همچنان این نام‌های مستعار را ارائه می‌دهد، زیرا حذف آن‌ها می‌تواند نرم‌افزارهایی را که انتظار رفتار قدیمی را دارند از کار بیندازد. حفظ این محدودیت هزینهٔ اندکی دارد، در حالی که کنار گذاشتن آن تقریباً هیچ مزیتی جز در دسترس قرار گرفتن چند نام فایل جدید برای کاربران نخواهد داشت.

پس آن‌ها باقی می‌مانند؛ بیست‌ودو واژه که در تک‌تک پوشه‌های درایوتان محفوظ مانده‌اند و در انتظار چاپگر خطی‌ای هستند که هرگز از راه نخواهد رسید.

بفرمایید، سعی کنید نام آن پوشه را CON بگذارید. طرف حساب شما Windows ۱۱ نیست؛ بلکه تصمیمی در سال ۱۹۸۳ برای حفظ سازگاری است که به محل استقرار چاپگر مربوط می‌شود.

منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Oluwademilade Afolabi است. مشاهده مقاله اصلی