Run a Fix safely

Applies to: Photo Date Rescue for Windows, version 3.0.4. Last verified: 30 July 2026. Every statement on this page was checked against the shipping 3.0.4 build. If you are on an older or newer version, the behavior may differ — check What’s new for changes.

A Fix is the one operation everything else in PDR is built around. You point PDR at the folders, drives and export archives that hold your photos, it works out when each picture was actually taken, and it writes corrected copies into a destination you choose, filed by date. This page is the reference we cite from our comparison table, so each part of a run has its own permanent link. Where the answer is “no” or “only partly”, it says so here in the same words the comparison uses.

Three words are used throughout, and they mean different things:

• Sources — the folders, drives and archives you add. PDR reads them and never writes to them.
• The destination — the folder you choose for the results. This is the only place a Fix creates or changes anything.
• A run — one press of Run Fix. Reports, duplicate decisions and cancellation are all scoped to a single run.

The order of a run is always the same: add sources, analyze, preview, choose how the output is filed, then run the Fix. You can stop at any point before Run Fix and nothing has been written.

---

At a glance

---

What happens to your original files

Nothing. This is the part of a Fix worth being certain about, so it is stated first. A Fix copies. It does not move, rename, re-date or delete anything in the folders you added as sources. When a run finishes, those folders are byte-for-byte as you left them, and you still have to decide for yourself whether to keep them.

PDR does write corrected dates into the picture files themselves — but into the copies at your destination, never into the file it read. That is not a setting you can get wrong; there is no path through a Fix that writes back to a source.

Limitations

• The date is written into the copy for photos, not videos. A video is copied and filed by its derived date, but the date is not written inside the video file.
• Not every date is written in. Dates PDR is confident about, and dates it recovered from a filename, are written into the copy. Dates it could only guess from a file timestamp are used to file and name the copy but are not written into it, unless you turn that on. See working out the date without being told it.
• Because it copies rather than moves, you need room for both. A run needs free space at the destination for everything it is about to write. See measuring the collection before you start.
• Setting a date by hand in Needs dates is a different operation and does not touch files at all — it updates PDR’s own record. See finishing by hand the photos it could not date confidently.

---

Adding folders, drives and export archives

Yes. One run can mix a folder on your PC, an external drive and a set of Google Takeout ZIP archives. Each thing you add becomes a card in the workspace showing what PDR found in it, and analysis then treats them as one pile rather than as separate jobs.

To do it

1. In the workspace, choose Add Source.
2. Pick a folder or a whole drive, or pick one or more ZIP archives. A Takeout export that arrived as several numbered ZIPs can be selected together — see exports that arrive split across several archives.
3. Wait for the pre-scan to finish. It tells you how many files there are, how much they take up, and how many are photos and how many are videos.
4. Repeat for every source you want in the run, then continue to analysis.

Limitations

• Archives have to be unpacked before they can be read. PDR does that for you, into a working folder on the drive you chose as your destination. That folder needs roughly as much free space as the contents of the archive, on top of the space the results will take.
• ZIP is the archive format PDR unpacks on its own. RAR archives depend on extraction software already installed on your PC. See bringing folders, drives and export archives into one run.
• Adding a source is not indexing it. Nothing is read in detail until you start analysis, and nothing is written until you run the Fix.
• There is no drag-and-drop onto the window. Sources are added through Add Source and the folder picker, and nothing else. Dragging a folder onto PDR does not add it.
• A source on a NAS or network share is added the same way. Browse to its mapped drive letter, or type the UNC path — \\server\share — into the picker. Reading across a network is slower than reading a local disk, and renamed-duplicate detection is skipped for network sources. See recognizing a duplicate that has been renamed.

---

Being told what you are about to process, and stopped from adding it twice

Yes. Two checks run when you add a source. The first is the Pre-Scan Results panel: before any analysis, PDR counts the files, adds up their size, splits them into photos and videos, names the kind of storage they are on, and estimates how long analysis will take — using how fast that storage actually read during the scan, not a fixed guess. Above about 5 GB it also suggests copying the files to a directly connected drive first, because that is usually the difference between an hour and an afternoon.

The second check is for sources you have already added. Adding the same folder again is refused, and the card you already have is highlighted instead. PDR also tries to catch the case where the same folder arrives by a different route — the same drive returning on a different letter, for instance — by comparing the folder name against the file count and total size of what is already in the run.

Limitations

• The content check has a time limit, and giving up looks like no match. On a very large or very slow folder the check can run out of time. When it does, PDR treats the folder as new and adds it. You would then process the same pictures twice in one run, and it is duplicate handling, not this check, that saves you.
• It compares folders, not photographs. Two different folders that hold some of the same pictures are both added, correctly. Overlap between sources is a duplicate question, not an add-source question.
• The pre-scan estimate is an estimate. It is the only timing figure PDR gives you, and it is calculated before any file has been decoded.
• PDR does not warn you when your sources and your destination are on the same drive. That arrangement is slower and gives you no protection if the disk fails, and PDR will let you do it without comment. Choose a different drive if you can.
• Whether the destination is a sensible choice at all is checked separately — see choosing which drive should hold the library and being stopped before a run that will not fit.

---

Working out the dates before anything is copied

Yes, and it is entirely separate from copying. When you choose Analyze, PDR walks every source, reads what each file can tell it about when it was taken, and produces a proposal for each one: a date, how that date was arrived at, a confidence tag, a new filename, and whether it looks like a duplicate of something else in the run. A progress display shows the counts moving. At the end of analysis your photos have not been touched and your destination is still empty.

All of that happens on your machine. No file, no filename and no folder path is sent anywhere to be analyzed. See where processing happens, and what leaves the machine.

Limitations

• Your sources come back when you reopen PDR, and are cleared once a Fix finishes. Both of those are on by default and both can be switched off in settings. If you turn off remembering, closing PDR discards the sources and the analysis that went with them.
• A file it cannot date is still included. It is filed and named from the best information available, tagged with low confidence, and offered to you afterwards in Needs dates. Nothing is silently dropped for lack of a date.
• How the date is worked out is documented separately. Which sources of evidence are used, in what order, and what each confidence tag means, are on working out the date without being told it.
• We publish no throughput figure. How long analysis takes depends on your storage, your files and your machine. The pre-scan estimate is what PDR will commit to, and we are not going to put a number on this page that we cannot stand behind for your collection.

---

Seeing what it intends to do before you commit

Only partly, and the limit is a real one. Preview Changes lists your files with the current name beside the proposed new name and the confidence tag for the date behind it, so you can see the shape of what is about to happen before you commit to it. What it does not do is let you act on any individual row.

To do it

1. Finish analysis.
2. Choose Preview Changes.
3. Read down the list. Old name on the left, new name on the right, confidence alongside.
4. If it looks wrong, close the preview and change your sources or your settings. If it looks right, close it and choose how the output is filed.

Limitations

• You see the first 100 files and no more. Below the list PDR tells you the true total — “Showing first 100 of 43,918 files” — and there is no way to page through the rest, sort them, or jump to a particular file. On a large run the preview is a sample, and you should read it as one.
• No row can be deselected. The preview is a review step, not a selection step. There is no tick box to exclude a file and no way to fix a wrong date from here. It is all of it or none of it.
• Low-confidence files are not brought to the top. The files most worth looking at are not sorted into the first 100; they are wherever they happen to fall.
• Correcting dates one at a time happens after the run, not before it — see finishing by hand the photos it could not date confidently, and showing what it intends to change before committing.

---

Filing the results by year, month or day

Yes. You choose one of three folder structures for the destination, and PDR shows you an example of each as you pick:

• Year — 2024/
• Year / Month — 2024/03/
• Year / Month / Day — 2024/03/15/

Inside those folders the copies are renamed so that the date is in the filename and sorting by name sorts by time. What arrives is ordinary folders of ordinary files — they open in Windows, in any photo app, and on any other computer, with or without PDR. See building filenames from capture date, camera and sequence.

Limitations

• One structure for the whole run. You cannot file videos by month and photos by year, or treat one source differently from another.
• Changing your mind means running again. There is no command that re-files an existing destination into a different structure. You would run the Fix again into a new destination and then remove the old one yourself.
• A wrong date puts a photo in the wrong folder. The structure is only as good as the dates behind it, which is why the confidence tags matter. See choosing whether the result is filed by year, by month or by day.

---

Keeping the original format, or converting to JPG or PNG

Yes, for photos. The Photo Format control offers three choices for the copies a Fix writes:

• Keep Originals — the default. No conversion. The copy is the same picture data in the same format.
• JPG — smaller files, opens everywhere. Saved at quality 92.
• PNG, labeled Full Quality — every pixel preserved exactly. Files typically run 2.5 to 3 times the size of the JPG equivalent, and the run takes roughly four times as long as JPG on the same hardware.

Limitations

• Videos are never converted. This control applies to photographs only. Video files are copied as they are, whatever you pick.
• JPG is lossy, and quality 92 is a judgment, not a promise. The picture is re-encoded. It is close, and for most photographs the difference is not visible, but it is a new file rather than your file.
• A converted copy carries the corrected date and not necessarily much else. PDR writes the date into the converted file. It does not undertake to carry every other piece of metadata the original format held across into the new one. If you care about what is inside the file, keep the originals.
• Extension tidying only happens when you keep originals. On that setting PDR normalizes .jpeg to .jpg and .tiff to .tif so a folder does not end up with two spellings of the same thing. The picture data is untouched; only the name changes.
• There is no way back. Converting is a choice you make before the run. Nothing in PDR turns a converted copy back into the format it came from — your originals are still where they always were.

---

Recognizing a duplicate that has been renamed

Usually, and this section is specific about when it does not. Duplicate skipping is on by default. Normally PDR compares a fingerprint of a file’s actual contents, which is what lets it recognize that IMG_4471.JPG and holiday-copy-2.jpg are the same photograph and write only one of them. That is the behavior you want from a messy pile of exports, and it is the behavior you get most of the time.

In three situations PDR quietly uses a weaker test instead — filename and file size — and does not tell you it has:

• Files larger than 500 MB.
• Sources on a network drive or inside a cloud-sync folder such as OneDrive, Dropbox, Google Drive or iCloud Drive.
• Files already sitting at the destination that PDR has not yet indexed.

Limitations

• The “thorough duplicate matching” setting does not override those three cases in 3.0.4. Its label reads as though turning it on forces the content fingerprint everywhere. It does not. Part of the pipeline never reads the setting at all, so the fallbacks above still happen with it switched on. This is a defect we have recorded, not a subtlety, and until it is fixed you should plan around the fallback rather than around the toggle.
• Filename and size can be wrong in both directions. Two genuinely different photographs that happen to share a name and a byte count are treated as the same file and one of them is skipped. The same photograph saved twice at different sizes is treated as two files and both are written.
• PDR does not judge pictures to be similar. There is no near-duplicate or visually-alike review, and nothing that picks the sharper of two shots taken a second apart. Duplicate means identical contents, or the fallback’s guess at it.
• Skipping duplicates makes the destination smaller than the source on purpose. That is the point, but it means the destination is not a mirror. See making a second copy of your photos.
• The decision is made for you, not offered to you. You are not shown the pair and asked which to keep. The run’s report records what was skipped and which file was kept in its place — see knowing which copy was kept when a duplicate is skipped.

---

When a file of that name is already at the destination

Yes, it is handled, and nothing is overwritten. Two files taken in the same second, or a second run into a destination you have used before, can produce a proposed filename that already exists. PDR never writes over what is there. If the existing file has the same contents, the new one is skipped as a duplicate. If it is genuinely a different picture, PDR adds a number to the end of the name — _001, _002 and so on — and writes it alongside.

Limitations

• It happens automatically and you are not consulted. There is no prompt asking which file to keep, no “apply to all”, and no chance to rename the incoming file yourself. You find out afterwards, from the report or by looking at the folder.
• Numbered names are a safety net, not a filing system. A destination you have run into several times will accumulate suffixed files, and telling apart a genuine burst of shots from the residue of repeated runs is left to you.
• The search for a free name is not infinite. If ten thousand numbered variants of the same name already exist, PDR gives up on that file and records it as an error rather than continuing to count.
• Not overwriting is not the same as verifying. PDR does not read the written file back to confirm it arrived intact — see verifying a copy afterwards.
• Reversing a duplicate or collision decision after the event is covered on reviewing and reversing duplicates, collisions and moves.

---

Running a Fix to a NAS or network share

Yes, and PDR changes how it works when it sees one. A mapped network drive or a UNC path such as \\server\share is recognized as a network destination. Rather than write each file across the network as it is produced, PDR builds the results in a staging folder on your own machine first and then transfers them across in one pass. The progress display tells you which of the two phases you are in. This is usually far faster than the file-by-file alternative and it copes better with a connection that stutters.

Limitations

• If the transfer fails, the message understates it. PDR keeps the local staging copy so the run does not have to be repeated, and tells you it has not modified anything at the destination. That sentence is not always true: files transferred before the failure are already there. Look at the destination yourself before you assume it is empty.
• There is no resume. Nothing records how far a transfer got so that a later attempt can pick it up. An interrupted transfer is started again from the beginning.
• Nothing is read back to check it. No checksum is compared against the source after the files land. See verifying a copy afterwards.
• Staging needs local disk space. The run is built on your own machine before it moves, so you need room for it there as well as at the destination. If the staging folder cannot be created, PDR falls back to writing straight across the network and you lose the speed benefit.
• Sources on a network drive change duplicate handling. See recognizing a duplicate that has been renamed.
• Network means your own network. There is no cloud destination of any kind. See sending a copy off this machine.

---

Stopping a run part-way

Yes. Both analysis and the copy itself can be canceled from the progress display, and the window stays responsive while it happens. PDR stops at the next safe point, finishes what is already in flight, and hands you the result for the part that ran rather than an error.

Limitations

• Canceling stops the run; it does not undo it. Files already written to the destination stay exactly where they are. If you want a clean slate you delete them yourself.
• It is not instant. A copy already under way is allowed to finish rather than being cut off mid-file, so a large file can hold things up for a few seconds. That is deliberate — the alternative is a half-written photograph on your disk.
• Canceling during a network transfer leaves the staging copy behind. See running a Fix to a NAS or network share.
• Canceling while an archive is being unpacked leaves a working folder to be cleared. See clearing up after unpacked archives.
• There is no pause. You can stop, and you can start again from the beginning. There is nothing in between.

---

The record each run leaves behind

Yes. Every completed run saves a report, and the reports stay on your PC until you delete them. You reach them from Reports History in the ribbon at the bottom of the dashboard. A report is per-file, not just a set of totals: for each photograph it holds the original filename, the new filename, the date PDR settled on, the confidence and how that date was arrived at, where the file came from, where it went, whether the date changed and whether the date was written into the copy. Alongside that are the run’s totals — copied, skipped as duplicates, failed — and the errors can be expanded to see which files failed and why.

This is what makes a renamed file traceable back to the one you started with. See tracing a renamed file back to where it came from.

Limitations

• A report is a record, not a rollback. It describes what happened. There is no command that reads a report and puts the destination back the way it was.
• Each report covers one run and nothing else. There is no running total across runs and no place that collects repeat offenders, so a file that fails every time looks like a fresh one-off on each occasion.
• Nothing chases you. The report is there if you open it. Close the window without reading it and the failures are not raised again.
• Reports list full paths and filenames. They sit on your own disk and go nowhere, but they do describe where your photographs live, so treat one as you would any other document that does.
• Deleting a report deletes only the report. Your photos, your destination and PDR’s library are unaffected — and the record of that run is then gone.

---

Getting that record out of PDR

Yes, in two ways. The one that happens without you asking is the catalog: by default, after a Fix, PDR writes PDR_Catalogue.csv and a matching text file to the top of your Library Drive, listing every file’s original name against its new one. It accumulates across runs rather than being replaced, and it can be regenerated at any time.

The second way is a manual export of one particular run, as a CSV spreadsheet or a plain text file. The CSV is one row per file with named columns, so it opens in Excel or any spreadsheet and can be searched, sorted and filtered like any other data.

Limitations

• The per-run export buttons are hidden until you turn them on. In settings there is a switch for manual report exports, and it is off in a new install. Turn it on and the export controls appear in Reports History; leave it off and the catalog is the only file you get.
• An export is an audit artifact, not a restore file. Nothing reads one back in to reverse a run or to reconstruct a library.
• It is a snapshot of that run at that moment. Files you move, rename or delete afterwards are not reflected in a CSV you exported last month.
• Exports contain full paths. If you are sending one to us for support, that is what you are sending.

---

Clearing up after unpacked archives

Yes, on a best-effort basis. A ZIP source has to be unpacked before it can be read, and the unpacked copy lives in a working folder — on the drive you chose as your destination once you have chosen one, and in your Windows temporary folder before that. Remove a source and PDR clears the working folder that belonged to it. Open PDR again with archive sources still in the workspace and it checks that their unpacked contents are still present, telling you if something has gone so you can unpack again rather than analyze a source that is no longer there.

Limitations

• A locked file stops the sweep. If another program — a viewer, an antivirus scanner, an open Explorer window — is holding a file, that file and its folder are left behind. PDR does not force the issue, and it does not come back later to try again.
• You can always delete the folder yourself. The working folder holds extracted copies only. Nothing in it is your only copy of anything, and removing it costs you nothing but the time to unpack again.
• Unpacking is not free. A run over archives needs space for the archives unpacked and for the results at the same time.
• Interrupted extractions are cleared, not resumed. Canceling during unpacking removes the partial contents rather than continuing from where it stopped.

---

Known gaps in 3.0.4

Collected in one place, because a Fix is the operation you are trusting with your photographs and these are the five things you should know before you press the button:

1. The “thorough duplicate matching” setting does not do what its label implies. Turning it on does not force content fingerprinting everywhere, so the three fallback cases under duplicates still apply. Recorded as a defect.
2. The preview is capped at 100 files and no row can be deselected. On a large run you are reviewing a sample and then committing to all of it.
3. A completed Fix cannot be undone. There is no command that reverses a run. Your sources are untouched, so nothing is lost — but clearing an unwanted destination is a job you do in Windows.
4. Nothing is verified after it is written. PDR does not read a copy back to confirm the bytes are right, at the destination or across a network.
5. A failed network transfer says the destination is unmodified, and it may not be. Check the destination rather than trusting the message.

When any of these changes, this page and the comparison table change together, and the “last verified” date at the top of this page moves with them.

---

How to check this page is still true

Every claim here describes behavior you can observe in the shipping build. If something on this page does not match what PDR does on your machine, that is a defect in one of the two, and we want to know: contact support. Tell us the anchor — for example /help/run-a-fix#summary — and we will either correct the software or correct the page.