can't pick writeprotected img-files

I am unable to reproduce this here. Using a sample image I have, I am able to mark it as read-only, and it will still write. Clicking on read will cause an error, though.

Remember, read is for reading a device and saving to an image file, write is to write an image file to a device.

If you still experience a problem, can you please let me know what version you are running, and what version of Windows? Also, if running on Windows Vista/7/8, you need to run this as administrator.

Thanks for having a look!

I'm running
Image Writer for Microsoft Windows
Release 0.6 (r46) - The "Tax Free" release
on Win7 Professional 64bit SP1.

Same problem when logged in as admin.

Ok, I've been able to reproduce it in Windows 7. Odd that it works in other versions. I may have to deep dive in to figure this out (hope not).

I plan on pushing a new release this weekend, as we are being featured on Sourceforge next week. Hopefully I can figure this out before then.

Well now, that was easier than expected. Fix committed, will release this weekend.

Well, in version 0.7 I can't create images anymore. I'm told that the file doesn't exist when trying to set a filename. Of course it doesn't exist yet!

Verified - looks like some of the "write" verification checks got copied into the read function. Oops. Will open a new bug on sourceforge.

Actually, this is a change in function due to the Windows File dialog issue. There are two file dialog methods; open & save. The program used to use the save function, which is why it worked when the file didn't exist.

Starting with Windows 7 however, this dialog will fail if the file exists AND is read-only. Switching to the Open method fixes that issue, but now the file must exist or it will fail (as you've seen). My solution to this was to allow the user to type a filename into the file window and if it doesn't exist the program will do the right thing. To reduce confusion on where the program will save new files, and to plan ahead for when we do a proper installation, I added a routine to find and set the default directory to the user's "Downloads" directory. This needs to be fine tuned, but works.

All of this was documented in the readme.

Ultimately, the real problem is that we need a generic file dialog, not an either/or (which is what we have available now). I will look into a better solution for the next release, but I wanted a working solution so that I could get this out.

Yeah, I was looking at it backwards earlier - the verification steps are in their appropriate places....