Windows เขียนการเปลี่ยนแปลงรีจิสทรีลงในดิสก์เมื่อใด

TL; DR:

ฉันสังเกตเห็นว่าถ้าฉันทำการเปลี่ยนแปลงรีจิสทรีแล้วปิดระบบ Windows 10 ของฉันอย่างหนักการเปลี่ยนแปลงรีจิสทรีจะไม่ปรากฏขึ้นหลังจากรีบูตเครื่อง

ฉันยังสังเกตเห็นว่าการลบไฟล์การจำศีลสามารถส่งผลกระทบต่อความสามารถในเครื่องมือการกู้คืน Linux เพื่อทำการเปลี่ยนแปลงรีจิสทรีของ Windows ในสถานะออฟไลน์ เครื่องมือดูเหมือนจะไม่สามารถทำการเปลี่ยนแปลงแบบถาวรหลังจากการลบไฟล์ไฮเบอร์เนต ฉันจะแสดงตัวอย่างเฉพาะด้านล่าง

ตัวอย่างที่ 1:

ฉันเพิ่มคีย์ชื่อ "1111" ลงใน "HKLM \ SOFTWARE" จากนั้นฉันปิดฮาร์ดไดรฟ์ลงกล่องโดยกดปุ่มเปิดปิดค้างไว้ 5 วินาที
เมื่อฉันดึงรีจิสทรีสำรองคีย์นั้นและค่านั้นหายไป:
(ภาพเหล่านี้ถูกแก้ไขเพื่อวัตถุประสงค์ในการจัดรูปแบบ)

ตัวอย่างที่ 2 :

ทำการเปลี่ยนแปลงในรีจิสทรี (โดยใช้ regedit)
ไฮเบอร์เนตระบบ
บู๊ตเป็นเครื่องมือกู้คืน Linux
ลบไฟล์ hibernation เพื่อติดตั้งดิสก์
อ่าน windows windows (จากเครื่องมือการกู้คืน)
การเปลี่ยนแปลงรีจิสทรีจะหายไป

ดูเหมือนว่าจะเท่ากับการปิดระบบอย่างหนักในกล่อง

ตัวอย่างที่ 3:

ฉันเห็นพฤติกรรมคนแปลกหน้าเมื่อฉัน:

จำศีลกล่อง
บู๊ตเป็นเครื่องมือการกู้คืน Linux และลบไฟล์ไฮเบอร์เนต
ทำการเปลี่ยนแปลงรีจิสทรี (จากเครื่องมือการกู้คืน)
รีบูทกล่อง

การเปลี่ยนแปลงเหล่านั้นจะไม่ปรากฏในรีจิสทรีเช่นกัน

แล้วเกิดอะไรขึ้นที่นี่?

Windows 10 เขียนการเปลี่ยนแปลงรีจิสทรีไปยังดิสก์เมื่อใด
ทำไมการลบไฟล์การจำศีล (ในตัวอย่างที่ 3) ทำให้การเปลี่ยนแปลงรีจิสทรีที่ทำจากเครื่องมือการกู้คืนไม่ปรากฏในการบูตครั้งถัดไป

หวังว่าจะได้คำอธิบาย!

windows-10 windows-registry hibernate

— Shrout1
แหล่งที่มา

"เขาเปลี่ยนรีจิสทรีไม่ปรากฏหลังจากรีบูต" - การเปลี่ยนแปลงรีจิสทรีจะไม่มีผลจนกว่าจะรีบูตและโดยทั่วไปจะต้องเริ่มต้น File Explorer ใหม่เท่านั้น ทุกอย่างขึ้นอยู่กับพฤติกรรมการเปลี่ยนแปลงรีจีสทรีที่ควรทำหากจำเป็นต้องรีบูตเครื่อง คีย์จริงถูกแก้ไขเมื่อมีการแก้ไขซึ่งจะตอบคำถามของคุณ

— Ramhound

การปิดเครื่องหนักหมายถึงอะไร กดปุ่มเปิดปิดค้างไว้จนกระทั่งปิดเครื่องหรือไม่ กระบวนการนั้นจะข้ามการเขียนแคชดิสก์ที่รออยู่

— DavidPostill

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

— Shrout1

@ Shrout1 - ทำไมคุณต้องบังคับให้เครื่องปิดแทนการปิดเครื่องอย่างปลอดภัย?

— Ramhound

@Ramhound ฉันกำลังทำการทดสอบเพื่อดูว่าเกิดอะไรขึ้นหากระบบไม่ได้ปิดลงอย่างสวยงาม ฉันรู้แบบสุ่ม แต่ฉันต้องรู้อย่างแน่ชัดว่าสิ่งนี้มีความมุ่งมั่นอย่างไรกับหน่วยความจำเพื่อที่เราจะได้ไม่สูญเสียสิ่งใดในระบบของเราหากไม่ได้จัดการอย่างถูกต้อง

— Shrout1

คำตอบ:

TL; DR: ปิดระบบของคุณอย่างถูกต้อง

การไฮเบอร์เนตไม่เกี่ยวข้องกับการปิดระบบมันเกี่ยวข้องอย่างใกล้ชิดกับ suspend-to-RAM (sleep) ยกเว้นเนื้อหาของ RAM ที่ผลักไปยังดิสก์เพื่อให้สามารถอ่านได้อีกครั้งและการทำงานต่อจากจุดที่ระบบหยุดทำงาน .

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

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

ในขณะที่ระบบถูกจำศีลจะมีโครงสร้างระบบไฟล์ที่สำคัญหลายอย่างที่อาจไม่ได้เขียนลงดิสก์และอยู่ใน RAM แทน เมื่อระบบกลับมาทำงานต่อจากโหมดไฮเบอร์เนตคาดว่าดิสก์จะอยู่ในสถานะที่เฉพาะเจาะจงมากและเป็นไปได้ว่าดิสก์แคชและไฟล์ระบบที่สำคัญจะได้รับการบันทึกลงในไฟล์ไฮเบอร์เนตแทนที่จะเป็นดิสก์จริง

หากคุณทำการปิดระบบที่เหมาะสม Windows จะล้างหน่วยความจำในการทำงานลงในดิสก์อย่างเหมาะสมจากนั้นให้ unmount ดิสก์อย่างสมบูรณ์ก่อนที่จะปิดเครื่อง

หากต้องการบังคับให้ปิดเครื่องอย่างเหมาะสมให้เปิดพรอมต์คำสั่งและพิมพ์

shutdown /s /f /t 0

/sคือ "ปิด" /fเพื่อบังคับและ/t 0หมายถึง "ตอนนี้" (เวลา = 0 วินาที)

หรือคุณสามารถปิดใช้งาน fastboot และโหมดไฮเบอร์เนต

อ่านเพิ่มเติมได้ที่HowtoGeek: การปิดเครื่องไม่ได้ปิดระบบ Windows 10 จนเต็ม (แต่จะเริ่มต้นใหม่หรือไม่)

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

แต่สิ่งที่เกิดขึ้นคือการบังคับให้ปิดระบบอย่างหนักคุณจะไม่ให้ระบบมีโอกาสเขียนการเปลี่ยนแปลงดิสก์อย่างปลอดภัย

ระบบไฟล์ที่ทันสมัยส่วนใหญ่เขียนขึ้นเพื่อทำการเปลี่ยนแปลงในวิธีที่ปลอดภัยที่สุดเท่าที่จะเป็นไปได้ ในอดีตพวกเขาถูกเรียกว่า "ปรมาณู" เช่นเดียวกับในการเปลี่ยนแปลงที่เกิดขึ้นหรือไม่

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

ด้วยการใช้คำสั่งนี้ดิสก์จะเกือบจะอยู่ในสถานะที่ง่ายต่อการซ่อมแซม

แต่ด้วยการบังคับให้ระบบของคุณปิดการทำงานโดยไม่คาดคิดคุณไม่สามารถรับประกันได้ว่าการทำธุรกรรมนั้นมีความคืบหน้ามากพอที่จะส่งต่อเมื่อมีการซ่อมแซมและโอกาสที่ระบบปฏิบัติการเช่น Linux จะไม่สนใจ Windows มากเท่ากับประวัติการทำธุรกรรม ไม่ใช่เพื่อทำการเปลี่ยนแปลงที่ย้อนกลับทุกอย่างแทนที่จะส่งต่อ

หากคุณบูตเครื่องใหม่ใน Windows อาจลองหรือสามารถซ่อมแซมดิสก์ได้อย่างถูกต้องเนื่องจากมีความรู้เกี่ยวกับระบบไฟล์มากขึ้น

— โมคุบิ
แหล่งที่มา

ขอขอบคุณ! ฉันขอขอบคุณคำตอบของคุณ :) ฉันปิดการจำศีลรีบูตเครื่องและทดสอบซ้ำอีกครั้ง ตัวอย่างที่ 1 มีผลลัพธ์เหมือนกันไม่มีไฟล์การไฮเบอร์เนตเกี่ยวข้อง ดูเหมือนว่าการเปลี่ยนแปลงรีจิสทรีจะถูกเขียนในบางช่วงระหว่างการออกจากระบบ / ปิดระบบ ... ฉันยังยอมรับว่าระบบอาจกำลังมองหาสถานะ "ดีที่สุด" เมื่อตื่นจากการไฮเบอร์เนตที่เสีย - มีแนวโน้มที่จะเรียกใช้การตรวจสอบความสมบูรณ์

— Shrout1

อืม ... ดังนั้นฉันจึงดาวน์โหลด sysinternals "sync" ซึ่งบังคับให้แคชเขียนไปยังดิสก์และนั่นไม่ได้ทำอะไรเลย (ยังคงสูญเสียคีย์ / ค่าเมื่อปิดระบบอย่างหนัก) ฉันยังรัน process explorer และดู Disk I / O ในคุณสมบัติของ Regedit มันอ่าน I / O แต่ไม่เขียน I / O นี่ทำให้ฉันคิดว่ามันอาจกำลังรอการปิดตัวลง ... คุณรู้หรือไม่ว่าเอกสาร M $ ที่แห้งมากเหลือเกิน ขอบคุณอีกครั้งสำหรับความช่วยเหลือของคุณ!!

— Shrout1

เจอร์นัล NTFS ไม่รับประกันเกี่ยวกับข้อมูลไฟล์ มันเป็นเพียงเพื่อให้ NTFS เมตาดาต้าที่สอดคล้องกันเพื่อให้คุณไม่จบลงด้วยการเสียระบบแฟ้ม ไฟล์แต่ละไฟล์ยังสามารถบันทึกการเปลี่ยนแปลงบางส่วนกับพวกเขาทำลายไฟล์ มีNTFS ของทรานแซคชันแต่ไม่แนะนำและไม่ค่อยได้ใช้ นี่คือสาเหตุที่เอ็นจินฐานข้อมูลเก็บรักษาเจอร์นัลของตัวเองเพื่อความสอดคล้องของข้อมูล ดูได้ที่blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

— Bob

@ Shrout1 นั่นคือการสันนิษฐานว่าการเปลี่ยนแปลงรีจิสทรีกำลังอยู่ในแคชการเขียนกลับ เป็นไปได้ทั้งหมดว่าพวกเขาจะจัดการแยกต่างหากแทนและสิ่งนี้ไม่เกี่ยวข้องกับระบบไฟล์แคชหรืออย่างอื่น ตัวอย่างเช่น Last Known Good Configuration จะได้รับการอัพเดตเมื่อเริ่มต้นสำเร็จเท่านั้น (ฉันไม่ทราบเกี่ยวกับการลงทะเบียนภายในที่เพียงพอเพื่อให้แน่ใจว่าเมื่อมีการบันทึกการเปลี่ยนแปลงแล้วTxRอาจเกี่ยวข้อง)

— Bob

มีเหตุผลที่คุณบังคับให้ปิดระบบหรือไม่? AFAIK ที่บังคับให้แอปพลิเคชั่นปิดเท่านั้นซึ่งไม่ได้ทำอะไรมากไปกว่าการปิดแอปพลิเคชันที่คุณไม่สามารถปิดได้และทำให้มีโอกาสมากขึ้นที่คุณจะสูญเสียการเปลี่ยนแปลงที่ไม่ได้บันทึกบางส่วนหากคุณไม่รู้ว่าคุณกำลังทำอะไร ทำหรือว่าคุณจะทำให้แอปพลิเคชันบางอย่างอยู่ในสภาพที่ไม่สามารถกู้คืนได้ - ฉันจะไม่เรียกว่าการปิดระบบ "เหมาะสม"

— NotThatGuy

ตามที่ระบุไว้ในหน้า MSDN สำหรับRegFlushKey :

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

อีกวิธีหนึ่งคือรีจิสตรีมีกลไก 'lazy flush' ซึ่งจะทำการแก้ไขรีจิสตรีในดิสก์ในช่วงเวลาปกติ นอกเหนือจากการดำเนินการฟลัชปกติการเปลี่ยนแปลงรีจิสทรีจะถูกฟลัชไปยังดิสก์เมื่อปิดระบบ การอนุญาตให้ 'lazy flush' เพื่อล้างการเปลี่ยนแปลงรีจิสทรีเป็นวิธีที่มีประสิทธิภาพที่สุดในการจัดการการเขียนรีจิสทรีไปยังที่เก็บรีจิสทรีบนดิสก์

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

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

— user914877
แหล่งที่มา

เฮ้! ฉันจะให้สิ่งนี้กับคุณหากคุณใส่ลิงค์ไปยังบทความ MSDN ต่อไปนี้: การบันทึกการเปลี่ยนแปลงรีจิสทรีของแอปพลิเคชันใน Windows 8 หรือ Windows Server 2012และเพิ่ม blockquote สั้น ๆ คำตอบของคุณทำให้ฉันลงหลุมกระต่ายไปที่บทความนั้นและโดยทั่วไปแล้วก็พูดในสิ่งเดียวกันกับที่คุณทำ ขอบคุณมาก ๆ เลย!

— Shrout1

แต่ไม่มีใครรู้ว่าผู้ใช้สามารถโทรRegFlushKey ได้อย่างไร

— สกอตต์

@Scott ดูเหมือนว่าจะต้องทำในรหัส ... บทความ MSDN ที่ปรากฏในโพสต์มีตัวอย่าง C ++ และฉันเคยเห็นมันนำมาใช้ใน C # ที่อื่น ไม่แน่ใจว่าสามารถทำได้จากบรรทัดคำสั่ง

— Shrout1

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

— Mehrdad

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

— พื้นฐาน

TL; DR: มันเป็นมากระมัดระวังในการทำเช่นนี้ในเวลาที่เหมาะสม

เอกสารเกี่ยวกับFSCTL_MARK_AS_SYSTEM_HIVEสิ่งนี้จะกล่าวถึง:

FSCTL_MARK_AS_SYSTEM_HIVEรหัสควบคุมแจ้งระบบไฟล์ว่าไฟล์ที่ระบุประกอบด้วยรังระบบรีจิสทรีของ ระบบไฟล์ต้องลบข้อมูลกลุ่มของระบบไปยังดิสก์ในเวลาที่เหมาะสมเพื่อหลีกเลี่ยงการหยุดชะงักและเพื่อให้แน่ใจว่ามีความถูกต้องของข้อมูล

ฉันไม่เชื่อว่ามีรายละเอียดใด ๆ ที่เปิดเผยต่อสาธารณะมากกว่านี้

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

— Mehrdad
แหล่งที่มา

โอ้ดีจัง! นั่นเป็นที่ชื่นชอบของใหม่ MSDN ลัทธิฉัน: เพียงแค่ช่วงเวลาที่เหมาะสม รายการโปรดก่อนหน้าของฉันคือ"ใช้ความระมัดระวังเมื่อระบุคำสั่งย่อย TOP ในแบบสอบถามที่มีตัวดำเนินการ UNION, UNION ALL, EXCEPT หรือ INTERSECT เป็นไปได้ที่จะเขียนแบบสอบถามที่ส่งกลับผลลัพธ์ที่ไม่คาดคิด "ซึ่งเป็นคำย่อสำหรับ " ไม่ดีและไม่ได้ทำในสิ่งที่คนมีเหตุผลคาดหวังและแทนที่จะแก้ไขมันเราจะจัดทำเอกสาร "

— davidbak

@davidbak: lol ในการป้องกันของ MSDN ฉันไม่เห็นรายละเอียดเพิ่มเติมว่าพวกเขาสามารถให้ผู้ใช้ควรพึ่งพา

— Mehrdad

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

— davidbak

@davidbak: ฉันคิดว่าคุณเป็นเพียงเล็กน้อย ... ตื่นเต้น :-P ฉันเดาว่านี่เป็นเอกสารเพื่อให้ไดรเวอร์ระบบไฟล์ทราบว่าไฟล์ใดมีกลุ่มรีจิสทรีของระบบซึ่งอาจเป็นสิ่งสำคัญที่พวกเขาจะไม่พยายามเขียนสิ่งใด ๆ ในรีจิสทรีในเวลาเดียวกันกับไฟล์นั้น กำลังถูกฟลัชไปยังดิสก์ ฉันไม่มีข้อพิสูจน์เรื่องนี้แม้ว่า; เป็นเพียงเหตุผลหนึ่งที่ฉันคิดว่าเป็นไปได้ มีข้อสงสัยอย่างหนึ่งที่ฉันมีเกี่ยวกับเรื่องนี้คือสาเหตุที่ทำให้ไดรเวอร์ดิสก์ไม่จำเป็นต้องรู้สิ่งนี้ด้วย

— Mehrdad