Automount during writing causes drive to enter read-only mode
After the format step, OSX mounts the drive which causes it to be read only. This leads to the write autorun.inf (or whatever the first file) to end in error. According to logs, the write is not retried if skip is chosen.
Expected behaviour:
- While the error dialogue is open, the drive can be ejected
- Add a button to retry the failed operation
- After ejecting the drive, the operation is retried
- After success, all files are written
Hello @etienne-paypay. Thank you for your report.
OSX mounts the drive which causes it to be read only
That's a weird behavior; it shouldn't act like that. WinDiskWriter doesn't send any R/O flags to the system disk manager after formatting the drive. Could you please provide me more information?
- Your macOS version
- Is it a real Mac or Hackintosh?
- What Windows image you're trying to 'burn' on your USB? (Link?)
- What configuration in WinDiskWriter you're using?
- Some brief info about your USB drive (like model, capacity)
Thank you!
Hi,
I was trying to burn Win11_24H2_English_x64.iso from https://www.microsoft.com/en-us/software-download/windows11
I am using a real Mac, macOS version: Version 14.7.1 (23H222)
This issue occurred for any configuration in WinDiskWriter.
USB drive is a SDDDC2-128G-G46
I don't think the WinDiskWriter has any issues after formatting, but I think the OS is getting in the way, and the current implementation does not recover. After ejecting from OSX, the remaining files are copied correctly, but the first file fails because it's not possible to eject before WinDiskWriter tries to copy. I think al that's needed is some way to wait until the drive is ejected before starting the copy process, or a way to retry a failed copy.
Hello. Although I never encountered an error like this, I can 100% agree with you: WinDiskWriter needs this kind of logic, especially the 'Retry' button and some kind of automatic write attempts to fix post-formatting issues on some computer configurations.
Few days ago I started the migration process from legacy Objective-C codebase to a more modern Swift. So your suggestions might be implemented in a future WinDiskWriter release, but it will take time, since a lot of stuff needs to be rewritten.
Currently, WinDiskWriter is built with a huge backwards compatibility in mind, so it can run even on ancient Mac OS X versions, but it introduced a lot of pain and wheel reinventions. So this migration in my case is a really important step.
Thank you, @etienne-paypay for your report. Now I'm aware about this issue, but it seems to be very rare among users.