File Locked or Read-Only in ExifToolGui: What to Do

ExifToolGui edits photo metadata by writing to the file itself, through Phil Harvey’s ExifTool. When Windows or the storage medium will not let the file be written, the edit cannot land — and the refusal has nothing to do with the GUI. This page explains the three ordinary reasons a file is locked or read-only, how to tell them apart, and the clean way to work around each one. A note on sourcing: the locking and read-only behaviours described here are general facts about how Windows and removable media work, stated as such — they apply to any program that modifies files, and ExifToolGui is simply the program you happen to be using. More fixes are collected in the Troubleshooting hub; the program itself is on the download page.

Case 1: the file itself is marked read-only

Windows files carry a read-only attribute. While it is set, programs are refused when they try to modify the file — the file can be opened and read, but not changed. Photos acquire this attribute in ordinary ways: copied from a disc, restored from a backup, or set deliberately long ago and forgotten. The check is direct: right-click the file in Windows Explorer, open Properties, and look at the Read-only checkbox at the bottom of the General tab. If it is ticked, clear it, apply, and make your edit again in ExifToolGui. For a whole folder of photos, the same attribute can be cleared for the folder’s contents in one operation from the folder’s Properties. If the attribute keeps coming back, the files are likely being re-copied from a read-only source each time — which is Case 3.

Case 2: the file is open in another program

A file in active use can be locked against changes by the program using it. Viewers, editors, and background tools that are reading or uploading the file can all hold it open. The symptom differs slightly from the read-only attribute: the file’s Properties look normal, nothing is ticked, yet writes fail while a particular program is running and succeed once it is closed. The diagnostic is simply to close candidate programs — start with whatever you opened the photo in — and retry the edit. If you edit photos straight from a folder that a sync service watches, be aware the service may hold files while it uploads them; pausing the sync or working on a local copy removes that variable. This is also the first thing to rule out when only some files in a batch refuse: those are usually the ones something else is holding.

Case 3: the location or the medium is read-only

Sometimes neither the file nor any program is at fault — the place the file lives refuses writes. The common versions, stated as general storage facts:

• Memory cards with a lock switch: many SD cards have a small physical slider; in the locked position the card is read-only to every program. Slide it to the unlocked position and reinsert the card.
• Discs and read-only media: files on a CD or DVD cannot be modified in place at all. Copy them to your PC first, then edit the copies.
• Folders without write permission: system folders, other users’ folders, and some network locations accept reads but not writes. Working on a copy in a folder of your own sidesteps the question entirely.
• Files copied from read-only sources can inherit the read-only attribute described in Case 1, which is why the two cases so often arrive together.

The universal workaround, and the working habit this site recommends for metadata editing in general, is: copy the photos to a normal folder on your PC, edit the copies in ExifToolGui, and only then move them where they belong. That one habit removes the medium, the permissions and most locking variables from the equation at once.

How this connects to edits not saving

A locked or read-only file is the most common underlying cause when ExifToolGui changes appear not to save: the GUI issues the write, ExifTool attempts it, the operating system refuses it. If your problem presents as edits vanishing rather than an explicit refusal, run the isolation routine in ExifToolGui Changes Not Saving — it tests one local file on a clean pairing and tells you within a minute whether you are dealing with a file problem or a program problem. And if reading metadata fails as well as writing, suspect the pairing before the files: the not-found guide covers the rename and exiftool_files checks. One reassurance to end on: a refused write leaves your photo untouched. Locked and read-only failures are frustrating precisely because they are safe — nothing was half-written.

Frequently asked questions

Can ExifToolGui override a read-only file for me?

No — and it should not. The read-only attribute and file locks are the operating system’s rules, and the GUI works within them like any other program. Clear the attribute, close the program holding the file, or edit a copy in a writable folder.

Only some files in my batch failed. Why those?

Because locking and attributes are per-file. The failures are the files that were open elsewhere, marked read-only, or sitting somewhere unwritable. Check one failed file individually — its Properties and what else has it open will usually explain the whole group.

Is editing copies instead of card originals really necessary?

It is the reliable pattern, not a strict rule. Working on copies in a local folder removes card locks, media limits and permission questions in one step, and your originals stay untouched until you are happy with the result. The GUI program files themselves are on the download page if you are setting up fresh.