لماذا لا يمكنني تغيير الملفات المستخدمة في Windows على غرار ما يمكنني في Linux و OS X؟

عندما تستخدم نظام التشغيل Linux و OS X ، لن يمنعك نظام التشغيل من حذف ملف قيد الاستخدام حتى الآن على Windows ، وبالتالي سيتم منعك من القيام بذلك. ما يعطي؟ لماذا يمكنك تعديل وحذف الملفات قيد الاستخدام على أنظمة مشتقة من Unix وليس Windows?

تأتي جلسة الأسئلة والأجوبة اليوم مقدمة من SuperUser-a subdivision of Stack Exchange ، وهي مجموعة مجتمعية مدفوعة من مواقع Q & A.

السؤال

يريد قارئ SuperUser the.midget أن يعرف لماذا يعامل Linux و Windows الملفات قيد الاستخدام بشكل مختلف:

أحد الأشياء التي حيرتني منذ أن بدأت استخدام لينكس هي حقيقة أنه يسمح لك بتغيير اسم الملف أو حتى حذفه أثناء قراءته. مثال على ذلك كيف حاولت بطريق الخطأ حذف فيديو أثناء تشغيله. نجحت ، وفوجئت عندما علمت أنه يمكنك تغيير أي شيء في ملف دون الاهتمام إذا كان يتم استخدامه في الوقت الحالي أو لا.

ما يحدث خلف الكواليس ويمنعه من حذف أشياء في Windows كما لو كان في لينكس?

الاجابة

سلط المساهمون في SuperUser بعض الضوء على الموقف من أجل. كتب عن دهشتها:

عند فتح ملف أو تنفيذه في Windows ، يقوم Windows بتأمين الملف في مكانه (هذا تبسيط ، ولكنه صحيح عادةً). لا يمكن حذف الملف الذي يتم قفله بواسطة عملية حتى يتم تحريرها. هذا هو السبب في كل مرة يقوم فيها Windows بتحديث نفسه ، تحتاج إلى إعادة تشغيله حتى يصبح ساري المفعول.

من ناحية أخرى ، لا تعمل أنظمة التشغيل الشبيهة بـ Unix مثل Linux و Mac OS X على تأمين الملف ، بل على قطاعات القرص الأساسي. قد يبدو هذا تمايزًا بسيطًا ، لكنه يعني أنه يمكن حذف سجل الملف في جدول محتويات النظام دون إزعاج أي برنامج يحتوي بالفعل على الملف مفتوحًا. بحيث يمكنك حذف ملف ما أثناء تنفيذه أو استخدامه ، وسيستمر وجوده على القرص طالما أن بعض العمليات بها مقبض مفتوح حتى ولو اختفى إدخاله في جدول الملفات.

يتوسع ديفيد شوارتز في الفكرة ويبرز كيف يجب أن تكون الأمور مثالية وطريقة ممارستها:

افتراضيات Windows إلى تأمين تلقائي إلزامي للملفات. UNIXES افتراضي إلى دليل ملف ، تأمين ملف تعاوني. في كلتا الحالتين ، يمكن تجاوز التخلف عن السداد ، ولكن في كلتا الحالتين لا تكون عادة.

يستخدم الكثير من كود Windows القديم واجهة برمجة تطبيقات C / C ++ (مثل fopen) بدلاً من واجهة برمجة التطبيقات (API) (مثل CreateFile). لا تمنحك واجهة برمجة تطبيقات C / C ++ أي طريقة لتحديد كيفية عمل الإجبارية ، حتى تحصل على الإعدادات الافتراضية. يميل "وضع المشاركة" الافتراضي إلى حظر العمليات "المتعارضة". إذا قمت بفتح ملف للكتابة ، يفترض أن تتعارض مع الكتابة ، حتى إذا لم تكتب في الواقع إلى الملف. الشيء نفسه لإعادة تسمية.

وهنا ، أين تسوء الأمور. بخلاف فتح للقراءة أو الكتابة ، لا توفر واجهة برمجة تطبيقات C / C ++ أية طريقة لتحديد ما تنوي فعله بالملف. لذا يجب أن تفترض API أنك ستقوم بأي عملية قانونية. نظرًا لأن القفل إلزامي ، سيتم رفض فتح يتيح إجراء عملية متعارضة ، حتى إذا لم يكن الغرض من الشفرة هو إجراء العملية المتعارضة ، ولكنه كان مجرد فتح الملف لغرض آخر.

لذلك إذا استخدمت الكود واجهة برمجة تطبيقات C / C ++ ، أو تستخدم واجهة برمجة التطبيقات الأصلية دون التفكير بشكل خاص في هذه المشكلات ، فسوف ينتهي الأمر بمنع المجموعة القصوى من العمليات المحتملة لكل ملف يتم فتحه وعدم القدرة على فتح ملف ما لم تكن كل عملية ممكنة يمكن أن تؤدي عليه بمجرد فتحه هو غير مقيد.

في رأيي ، ستعمل طريقة Windows أفضل بكثير من طريقة UNIX إذا اختار كل برنامج أوضاع المشاركة الخاصة به وفتح الأوضاع بحكمة وتعامل مع حالات الفشل. ومع ذلك ، فإن طريقة UNIX تعمل بشكل أفضل إذا لم تهتم التعليمات البرمجية بالتفكير في هذه المشكلات. للأسف ، لا تتوافق واجهة برمجة تطبيقات C / C ++ الأساسية بشكل جيد مع واجهة برمجة تطبيقات ملفات Windows بطريقة تتعامل مع أوضاع المشاركة ويتم فتح التعارض بشكل جيد. وبالتالي فإن النتيجة الصافية هي فوضوي بعض الشيء.

إليكم الأمر: هناك طريقتان مختلفتان لمعالجة الملفات تعطي نتائج مختلفة.

هل لديك شيء تضيفه إلى الشرح؟ الصوت قبالة في التعليقات. هل ترغب في قراءة المزيد من الإجابات من مستخدمي Stack Exchange الآخرين المحترفين بالتكنولوجيا؟ تحقق من موضوع المناقشة الكامل هنا.