Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automount during writing causes drive to enter read-only mode #29

Open
etienne-paypay opened this issue Dec 11, 2024 · 3 comments
Open

Comments

@etienne-paypay
Copy link

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:

  1. While the error dialogue is open, the drive can be ejected
  2. Add a button to retry the failed operation
  3. After ejecting the drive, the operation is retried
  4. After success, all files are written
@TechUnRestricted
Copy link
Owner

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!

@etienne-paypay
Copy link
Author

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.

@TechUnRestricted
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants