เพราะเหตุใดฉันจึงสามารถเปลี่ยนไฟล์ที่ใช้งานได้บน Windows อย่างที่ฉันสามารถทำได้บน Linux และ OS X?

สารบัญ:

วีดีโอ: เพราะเหตุใดฉันจึงสามารถเปลี่ยนไฟล์ที่ใช้งานได้บน Windows อย่างที่ฉันสามารถทำได้บน Linux และ OS X?

วีดีโอ: เพราะเหตุใดฉันจึงสามารถเปลี่ยนไฟล์ที่ใช้งานได้บน Windows อย่างที่ฉันสามารถทำได้บน Linux และ OS X?
วีดีโอ: play store บน คอมพิวเตอร์ pc วิธีโหลด แอปพลิเคชั่นลง คอม nox player เห็นผลจริง 2020 l ครูหนึ่งสอนดี 2024, มีนาคม
เพราะเหตุใดฉันจึงสามารถเปลี่ยนไฟล์ที่ใช้งานได้บน Windows อย่างที่ฉันสามารถทำได้บน Linux และ OS X?
เพราะเหตุใดฉันจึงสามารถเปลี่ยนไฟล์ที่ใช้งานได้บน Windows อย่างที่ฉันสามารถทำได้บน Linux และ OS X?
Anonim
 เมื่อคุณใช้ Linux และ OS X ระบบปฏิบัติการไม่สามารถหยุดคุณในการลบไฟล์ที่ใช้งานอยู่ใน Windows คุณจะไม่สามารถดำเนินการได้อย่างชัดเจน สิ่งที่ช่วยให้? ทำไมคุณสามารถแก้ไขและลบไฟล์ที่ใช้งานได้ในระบบที่ได้รับจากยูนิกซ์ แต่ไม่ใช่ Windows?
เมื่อคุณใช้ Linux และ OS X ระบบปฏิบัติการไม่สามารถหยุดคุณในการลบไฟล์ที่ใช้งานอยู่ใน Windows คุณจะไม่สามารถดำเนินการได้อย่างชัดเจน สิ่งที่ช่วยให้? ทำไมคุณสามารถแก้ไขและลบไฟล์ที่ใช้งานได้ในระบบที่ได้รับจากยูนิกซ์ แต่ไม่ใช่ Windows?

เซสชั่นคำถามและคำตอบในวันนี้มาถึงเราด้วยความอนุเคราะห์จากแผนก SuperUser ของ Stack Exchange ซึ่งเป็นกลุ่มของ Q & A ที่เป็นชุมชนที่ขับเคลื่อนด้วยชุมชน

คำถาม

ผู้อ่าน SuperUser the.midget อยากรู้ว่าทำไม Linux และ Windows ถึงใช้ไฟล์ที่ใช้งานแตกต่างกัน:

One of the things that has puzzled me ever since I started using Linux is the fact that it allows you to change the name of a file or even delete it while it is being read. An example is how I accidentally tried to delete a video while it was playing. I succeeded, and was surprised as I learnt that you can change just about anything in a file without caring if it’s being used at the moment or not.

ดังนั้นสิ่งที่เกิดขึ้นเบื้องหลังและป้องกันไม่ให้เขาจากการลบสิ่งต่างๆใน Windows อย่างที่เขาทำได้ใน Linux?

คำตอบ

ผู้ร่วมงาน SuperUser ได้ให้ความสำคัญกับสถานการณ์ของ the.midget Amazed เขียน:

เมื่อใดก็ตามที่คุณเปิดหรือดำเนินการแฟ้มใน Windows Windows จะล็อกไฟล์ไว้ในตำแหน่ง (ซึ่งเป็นข้อมูลที่ใช้ง่าย แต่โดยปกติจะเป็นจริง) ไฟล์ที่ถูกล็อคโดยกระบวนการจะไม่สามารถลบออกได้จนกว่ากระบวนการดังกล่าวจะเผยแพร่ออกไป นี่คือเหตุผลที่เมื่อ Windows มีการปรับปรุงตัวเองคุณต้องรีบูตให้มันมีผล

ในทางกลับกันระบบปฏิบัติการยูนิกซ์เช่น Linux และ Mac OS X ไม่ได้ล็อคไฟล์ แต่เป็นส่วนของดิสก์ที่อยู่ภายใต้ นี้อาจดูเหมือนแตกต่างเล็กน้อย แต่ก็หมายความว่าแฟ้มบันทึกในตารางระบบแฟ้มของเนื้อหาสามารถลบได้โดยไม่รบกวนโปรแกรมที่มีอยู่แล้วเปิดไฟล์ใด ๆ ดังนั้นคุณสามารถลบไฟล์ในขณะที่ยังคงใช้งานอยู่หรือใช้งานได้และจะยังคงมีอยู่ในดิสก์ตราบใดที่กระบวนการบางอย่างมีหมายเลขอ้างอิงเปิดอยู่แม้ว่าจะมีรายการในตารางไฟล์อยู่ก็ตาม

David Schwartz จะขยายความคิดและเน้นว่าสิ่งต่างๆควรจะนึกคิดได้ดีเพียงใดและปฏิบัติอย่างไร:

Windows defaults to automatic, mandatory file locking. UNIXes default to manual, cooperative file locking. In both cases, the defaults can be overriden, but in both cases they usually aren’t.

A lot of old Windows code uses the C/C++ API (functions like fopen) rather than the native API (functions like CreateFile). The C/C++ API gives you no way to specify how mandatory locking will work, so you get the defaults. The default “share mode” tends to prohibit “conflicting” operations. If you open a file for writing, writes are assumed to conflict, even if you never actually write to the file. Ditto for renames.

And, here’s where it gets worse. Other than opening for read or write, the C/C++ API provides no way to specify what you intend to do with the file. So the API has to assume you are going to perform any legal operation. Since the locking is mandatory, an open that allows a conflicting operation will be refused, even if the code never intended to perform the conflicting operation but was just opening the file for another purpose.

So if code uses the C/C++ API, or uses the native API without specifically thinking about these issues, they will wind up preventing the maximum set of possible operations for every file they open and being unable to open a file unless every possible operation they could perform on it once opened is unconflicted.

In my opinion, the Windows method would work much better than the UNIX method if every program chose its share modes and open modes wisely and sanely handled failure cases. The UNIX method, however, works better if code doesn’t bother to think about these issues. Unfortunately, the basic C/C++ API doesn’t map well onto the Windows file API in a way that handles share modes and conflicting opens well. So the net result is a bit messy.

คุณมีวิธีนี้: สองวิธีในการจัดการไฟล์ให้ผลลัพธ์ที่แตกต่างกันสองแบบ

มีบางอย่างที่จะเพิ่มคำอธิบายหรือไม่? เสียงในความคิดเห็น ต้องการอ่านคำตอบเพิ่มเติมจากผู้ใช้ Stack Exchange ที่มีความเชี่ยวชาญด้านเทคโนโลยีหรือไม่? ดูหัวข้อการสนทนาฉบับเต็มได้ที่นี่

แนะนำ: