چک دیسک
در محاسبات، CHKDSK (مخفف عبارت «check disk») یک نرم‌افزار سیستم و فرمان در داس، دیجیتال ریسرچ FlexOS , آی بی ام / توشیبا 4690 OS , IBM OS/2، مایکروسافت ویندوز و سیستم عامل‌های مربوطه است. چک دیسک یکپارچگی سامانه فایل بندی یک حجم را بازبینی می‌کند و تلاش می‌کند خطاهای منطقی فایل سیستم را برطرف کند. چک دیسک مشابه دستور fsck در یونیکس و شبیه به است که همزمان با codice_1 در ویندوز 9x و ام اس-داس 6.x وجود داشته‌است.
یک پیاده‌سازی ابتدایی از چک دیسک، CheckDisk بوده‌است که بخشی از عیب‌شناسی سخت‌افزار دیجیتال ایکویپ‌منت کورپوریشن بود که در اوایل دهه ۱۹۷۰ بر روی TENEX و TOPS-20 اجرا می‌شد.
codice_1 اولین بار در سال ۱۹۸۰ توسط تیم پترسون اجرا شد و در محصولات کامپیوتری سیاتل داس-۸۶ گنجانده شد.
این دستور در MS-DOS در نسخه‌های ۱ و بالاتر موجود است. codice_1 به عنوان یک فرمان خارجی پیاده‌سازی می‌شود. در نسخه‌های 2.x - 4.x ام اس-داس از codice_4 به عنوان فایل قابل اجرا استفاده می‌شود. در نسخه‌های ام اس-داس 5.x به بعد از codice_5 به عنوان فایل قابل اجرا استفاده می‌شود.
codice_1 و codice_7 در MS-DOS 5.0 دارای یک اشکال هستند که می‌تواند داده‌ها را خراب کند: اگر جدول تخصیص فایل یک دیسک از ۲۵۶ بخش(sector) استفاده کند، اجرای codice_8 می‌تواند باعث از دست رفتن داده‌ها شود و اجرای codice_7 می‌تواند نتایج غیرقابل پیش‌بینی ایجاد کند. این معمولاً دیسک‌هایی با ظرفیت تقریباً مضربی از ۱۲۸ مگابایت را تحت تأثیر قرار می‌دهد. این بر روی codice_10 و codice_11 که دارای datastamp از تاریخ 9 آوریل 1991 هستند صدق میکند. این باگ در نسخه MS-DOS 5.0a رفع شد.
codice_1 را می‌توان از , Windows Explorer, Windows Command Prompt,
Windows PowerShell یا Recovery Console اجرا کرد.
در سیستم عامل های Windows NT, همچنین codice_1 می‌تواند سطح دیسک را برای بد سکتور بررسی کرده و آنها را علامت‌گذاری کند (در MS-DOS 6.x و Windows 9x، این کاری است که انجام میدهد) نسخۀ Windows Server ازcodice_1 دارای RAID- aware است و در صورت سالم بودن سایر دیسک‌های مجموعه، می‌تواند به‌طور کامل داده‌ها را در بد سکتورهای دیسک در آرایه های یا
بخش‌هایی از فایل‌ها و دایرکتوری‌هایی که به عنوان مثال در نتیجۀ قطع شدن برق در حین نوشتن، یکی یا هر دو مورد بیش از حد بودن طول نام فایل و کاراکترهای نامعتبر در نام فایل، خراب تلقی می‌شوند، به فهرستی در زیر ریشه پارتیشن به نام codice_15 منتقل میشوند و به فایل‌ها و دایرکتوری‌های شماره‌دار هگزادسیمی عمومی(generic) تغییر نام داده میشوند که به ترتیب با codice_16 و codice_17 شروع می‌شوند.
در خانواده ویندوز NT، یک اسکن استاندارد codice_1 شامل سه مرحله آزمایش فراداده فایل است. به دنبال خطاها می‌گردد اما تا زمانی که صریحاً به آن دستور داده نشده باشد آن ها را برطرف نمیکند. همین امر در مورد اسکن سطح نیز صدق می‌کند - این آزمایش، که ممکن است روی دیسک‌های بزرگ یا با کارایی پایین بسیار وقت گیر باشد، انجام نمی‌شود مگر اینکه صریحاً درخواست شود. codice_1 برای انجام تعمیرات، انحصارا به دسترسی نوشتن ولوم نیاز دارد.
به دلیل نیاز به دسترسی انحصاری به درایو، codice_1 نمی‌تواند دیسک سیستم را در حالت عادی سیستم بررسی کند. در عوض، سیستم بیت کثیف را روی ولوم دیسک تنظیم می‌کند و سپس کامپیوتر را مجددا راه اندازی می‌کند(ریبوت). در طول راه اندازی ویندوز، یک نسخه ویژه از codice_1 به نام codice_22 (یک برنامه کاربردی حالت بومی) توسط SMSS.EXE شروع می‌شود و اگر بیت کثیف تنظیم شده باشد، سیستم فایل را بررسی و تعمیر می‌کند.
به دلیل نیاز به دسترسی انحصاری و ماهیت زمان‌بر عملیات codice_1 ، ویندوز ویستا یک مدل سلامت سیستم فایل جدید را پیاده‌سازی کرد که در آن سیستم‌عامل خطاها را در ولوم‌هایی که با آنها مواجه می‌شود برطرف می‌کند. در صورتی که مشکل جدی باشد و نیاز به اسکن کامل باشد، Action Center به کاربر اطلاع می‌دهد که در اولین فرصت ولوم را آفلاین کند.
ویندوز ویستا و ویندوز سرور ۲۰۰۸ علاوه بر ارائه فرمان codice_1 ، قابلیت خوددرمانی را که به‌طور پیش‌فرض روشن شده‌است، اضافه کردند. این قابلیت خطاهای سیستم فایل فیزیکی را شناسایی می‌کند و در حین پروسه آنها را برطرف می‌کند؛ بنابراین، بسیاری از مشکلاتی که قبلاً در اجرای codice_1 کشف شده بودند هرگز ظاهر نمی‌شوند. این قابلیت توسط فرمان codice_26 اداره می‌شود.
تمایل codice_27 برای اصلاح خودکار سیستم فایل در زمانی که کاربر آن را به صراحت درخواست نکرده و ممکن است بخواهد از پیش از داده‌های خود نسخه پشتیبان تهیه کند، مورد انتقاد قرار گرفته است، زیرا تلاش برای تعمیر ممکن است مسیرهای فایل و دایرکتوری را به هم بزند، تضعیف کند و از مالکیت خارج کند، مخصوصا در نصب مالتیبوت که در آن چندین سیستم عامل ممکن است به صورت تداخلی روی یک پارتیشن نوشته شده باشند.
قبل از انتشار ویندوز ۷، "InfoWorld یک" ادعا از نشت حافظه در codice_1 را گزارش کرد. بر اساس این گزارش، دستور codice_29 باعث می‌شود مصرف حافظه به حداکثر برسد و سیستم از کار بیفتد. Randall C. Kennedy از "InfoWorld" گزارش اصلی را به " منابع مختلف وب " نسبت داد و گفت که در آزمایشات او، اگرچه خرابی را تجربه نکرده‌، مصرف حافظه به بالای ۹۰٪ رسیده‌است. با این وجود، کندی مصرف حافظه را یک باگ حیاتی که راه اندازی ویندوز ۷ را از مسیر خود خارج می‌کرد، در نظر گرفت و مایکروسافت را محکوم کرد. تام وارن از Neowin اهمیت ارزیابی کندی از افشای اتهامی رد کرد. استیون سینوفسکی از مایکروسافت نیز پاسخ داد که مایکروسافت نیز نمی‌تواند یک خرابی را بازتولید کند، اما طراحی مایکروسافت برای بهبود عملکرد باعث مصرف بالای حافظه میشود، نه نشت. Ed Bott از "ZDNet" نیز این ادعا را با آزمایش‌های خود بررسی کرد و مشاهده کرد که هیچ خرابی ای رخ نمی‌دهد. بات با اشاره به اینکه codice_29 ، بنا بر نوع طراحی، زمانی که ویندوز آنلاین است روی درایو سیستم کار نمی‌کند، نتیجه‌گیری کرد: «مسلماً این یک خاصیت است، نه یک باگ، و احتمال اینکه سیستمی از این طریق خراب شود، بسیار بسیار کم و کاملاً قابل اجتناب است."
DR DOS 6.0 همچنین شامل یک پیاده سازی از دستور است.
نسخه FreeDOS توسط Imre Leber توسعه یافته و تحت مجوز GNU GPL 2 است.
پیاده سازی ReactOS بر پایه یک کلون رایگان است که در سال 1998 توسط مارک راسینویچ برای سیس اینترنالز توسعه داده شد.در سال 1999، توسط Emanuele Aliberti با ReactOS تطبیق داده شد و ولوم‌ها را با استفاده از سیستم فایل FAT32 پشتیبانی می‌کند. این فرمان از ولوم‌ها با استفاده از سیستم فایل Btrfs پشتیبانی نمی‌کند، اگرچه ReactOS از نسخه 0.4.1 از آن پشتیبانی می‌کند.