Context Navigation

← Previous Change
Ticket Comment History
Next Change →

Changes between Initial Version and Version 1 of Ticket #17477, comment 5

Timestamp:: Sep 8, 2019 2:05:03 AM (5 years ago)
Author:: moehrmoehr

Legend:

: Unmodified
: Added
: Removed
: Modified

Ticket #17477, comment 5

initial	v1
3	3	Anyway, here's the detailed description of what happened, in case it is of use to anyone.
4	4
5		The host is a MacBook Pro 13" Mid 2012 running macOS 10.14.5. I was in the same situation as the OP - I had a Windows 10 VDI that I tried to compact, and the progress stopped after 80% (or at least it took unusually long). At some point after that, I was no longer able to run ls -l in the directory with the VDI - the command hung forever and could not be stopped with Ctrl+C, or even with a SIGKILL. The --compact operation could not be stopped either, so I tried to shut down my host system - which also hung, so I had to force shutdown by long pressing the power button. (Even Ctrl+Cmd+Power did not work, which normally functions as a slightly softer reset than long-pressing Power.)
	5	The host is a MacBook Pro 13" Mid 2012 running macOS 10.14.5 and VirtualBox 6.0.12. I was in the same situation as the OP - I had a Windows 10 VDI that I tried to compact, and the progress stopped after 80% (or at least it took unusually long). At some point after that, I was no longer able to run ls -l in the directory with the VDI - the command hung forever and could not be stopped with Ctrl+C, or even with a SIGKILL. The --compact operation could not be stopped either, so I tried to shut down my host system - which also hung, so I had to force shutdown by long pressing the power button. (Even Ctrl+Cmd+Power did not work, which normally functions as a slightly softer reset than long-pressing Power.)
6	6
7	7	After that I booted into recovery mode and ran a repair on the APFS volume. The repair process showed a few errors ("error: directory valence check: directory (old 0x13): nchildren (1) does not match drec count (0)", and a second error which I unfortunately did not write down before closing the log). I'm not sure if it actually performed any repairs, but the repair process claimed to be successful. After rebooting the problem persisted, trying to ls the directory in question hung with the same behavior as before. Repairing the volume a second time fixed the problem for some reason.