Protecting the library itself

Your index, your settings and your corrections are work too. This is what Photo Date Rescue does to keep them safe — and, in the same plain words, what it does not.

Applies to: Photo Date Rescue for Windows, version 3.0.11. Last verified: 17 September 2026. Every statement on this page was checked against the shipping 3.0.11 build — both the source and the packaged bundles — and deliberately not against our own feature list. If you are on an older or newer version, the behavior may differ; check What’s new for changes.

This page is the reference we cite from our comparison table. Each capability below has its own permanent link, so a claim about PDR can always be traced to the paragraph that supports it. Where the honest answer is “no” or “only partly”, this page says so in the same words the comparison uses. We would rather publish a limitation about ourselves than a strength we cannot stand behind.

This page is deliberately not about backups. Whether a second copy of your photos exists somewhere else is a different question, and it has its own page at Backing up. What follows is narrower and less comfortable: whether the working library resists damage in ordinary, everyday use.

It is worth saying up front that this is the task PDR scores worst on, and we have published it anyway. PDR is a repair tool. Its whole purpose is to change your files — to write correct dates into photos that have the wrong ones. A tool built to write is never going to win a category that rewards leaving things alone, and several answers below are “no” for exactly that reason rather than through neglect. Where the “no” is genuine neglect, we say that too.

At a glance

The first seven questions below are the ones the comparison table asks of every product, PDR included. They were written before any product was examined.

Question	PDR 3.0.11
Are my original files left alone?	Yes — the correction is written to a copy, never the source
Does PDR check its own index for damage?	No — no check of any kind runs
Can a damaged index be rebuilt without losing my work?	Partly — a rebuild keeps your names and albums, but loses who is in which photo
Does it survive a crash or a power cut?	Partly — the library survives; the last few changes may not
Can I export my settings and take them with me?	No — there is no export at all
Does it notice files changed outside PDR?	No — changed files go unnoticed, missing ones are dropped in silence
Does it record what it changed, and when?	No — the routine exists but nothing calls it, so no log is ever written
Can I go back to several earlier states of the library, not just the most recent copy?	Partly — several restore points, but some are duplicates and the dates shown are wrong
Can I undo a whole saved batch of date corrections in one step?	No — nothing undoes a saved batch; restoring a backup is the only way back
Am I stopped before two computers damage one portable library?	No — the second machine is labeled read-only but can still write
Can I see what is inside a backup before I restore it?	Partly — the recovery routes count it; the everyday list shows a size and an unreliable date

Whether your original files are left alone

They are, and it is not optional. A Fix run never writes to the photo you pointed it at. It copies each file into your library folder first, and the corrected date is written into that copy. The source file is opened for reading and nothing else: it is not rewritten, not renamed, not moved and not deleted. There is no in-place mode and no setting that turns one on, so leaving your originals alone is not a preference you can get wrong.

This is the whole shape of the product, so it is worth being concrete about what you end up with. Your source folder is exactly as it was. Alongside it, in the library folder you chose, there is a new copy carrying the right date, renamed to a date-ordered filename. PDR keeps a record of what that file used to be called, so the original name is not lost either.

This holds even when you ask PDR to move a library to another drive. A move copies every photograph to the new drive, checks each copy against the original by hash, points the library at the copy, and then leaves the original exactly where it was. PDR tells you so, and you clear the old drive yourself in Windows, where you can see what you are deleting. The reason is worth stating plainly rather than dressing up as a feature: on Windows, nothing available to PDR can guarantee that the file it is about to delete is still the same file it just copied — a drive letter can be handed to a different disk in between — and rather than accept even a small chance of deleting the wrong photograph, PDR deletes nothing at all. The cost is that a move needs room on both drives at once, and that you have a tidying-up job afterwards.

Two consequences follow. The first is that a Fix run costs disk space, because a corrected photo is an additional file rather than a changed one. The second is that the correction is written into the copy's own metadata rather than held in a private database, so it travels with the photo — move that copy to another machine, or open it in another program, and the right date is simply there.

Indexing, browsing and searching write nothing at all, to originals or copies.

Limitations

Videos get no metadata write. The copy is placed and renamed by date, and the date is recorded in the index, but no timestamp is written inside the video file itself. Move that copy somewhere PDR is not running and the date lives only in its filename.
HEIC and RAW copies get EXIF dates but no XMP date. Some programs read only the XMP date, and for those the copy will still look undated. This is a known gap rather than a decision.
The copy's own modified time is the time it was copied — not the capture date. A photo taken in January 2020 and fixed in May 2026 carries a 2020 date inside the file and a 2026 modified time outside it, so sorting a folder by “date modified” in Windows Explorer will not show you the photo dates.
There is one place PDR will overwrite a file, and it is not a source photo. In the viewer, an enhanced image can be saved either as a new file or over the top of the one you were viewing. The default is a new file, and the file at risk is the library copy, never the original you imported.

Whether PDR checks its own index for damage

It does not. Not on startup, not on a schedule, and not on demand. PDR never asks the live database whether it is healthy, and it has no way to tell you that it is not.

One thing near it does get checked, and it is worth being exact about the difference. Every backup copy PDR makes is opened and counted the moment it is written, and a copy that will not open, or that opens and holds nothing, is thrown away rather than offered to you in the restore list. That protects you from restoring a copy that was never really written. It says nothing at all about whether the live index is sound, which is what this section is about.

This is a real gap rather than a design trade-off, and we are not going to dress it up. The database engine PDR uses offers a built-in consistency check that most applications run occasionally; PDR does not call it. If the index were damaged — by a failing disk, say — the first you would know is that searches started returning the wrong thing, or nothing.

What follows from that matters for the next section. Because nothing detects damage, nothing can prompt you to fix it. The repair described below is real and it works, but you have to decide to run it yourself, on a hunch.

Rebuilding a damaged index

There is a rebuild, and it costs you more than time. PDR can walk your library folders again and reconstruct the index from what it finds. The people you have named, the albums you have made and the family trees you have saved do survive, because they live in separate tables. What does not survive is the links between them and your photos. Face matches, AI tags and album membership are attached to the file entries, so when stale file entries are cleared those links go with them — and a rebuild only puts back the files it finds missing. It cannot reattach what was already deleted. So you get your photos and your list of people, and not the knowledge of who is in which photo.

If you want everything back rather than most of it, restore a dated copy instead of rebuilding. That is the route that keeps the connections.

You are also not relying on the rebuild, because PDR keeps dated copies of the index without being asked. A copy is taken every time PDR starts, before the live index is opened — but only when your library has actually changed since the last one, so the copies you have reach back to the last two times something changed rather than the last two times you opened the app. PDR keeps two.

Corrected 11 September 2026. This page used to describe a ladder here: the last five launches, then older ones promoted so that one survived per day for a week and one per week for a month. That ladder was real, and it has been removed. The next two paragraphs are why.

The first reason: most of those files were the same file. We counted and fingerprinted every copy on the machine we test against. There were thirteen launch copies — and only eight distinct states among them. Six of the thirteen, spanning three days and five separate launches, were byte-for-byte identical. A copy was taken whether or not anything had changed, and the ladder then sorted and bucketed those copies by a modification time they inherited from the library rather than took from the clock, so identical files all landed in one day’s bucket. Both halves of that are fixed: a copy is only taken when your library changed, so the duplicates are never created, and each copy is stamped at the moment it is written.

The second reason: those copies are not free. On the same machine — a real library of around forty thousand photos, with an index of about 370 MB — the backup folder had reached 8.9 GB by 3 September 2026: launch copies, the automatic People copies described below, and a leftover nothing would remove. All of it on the system drive, quietly, without ever asking. On a bigger library it would have been far worse.

So there is now a hard ceiling of six copies — two taken at launch, two taken before risky operations, and two you take by hand, and no more of any kind. For the library above that is about 2.2 GB at absolute worst against 8.9 GB, and in practice less, because a launch copy is only taken when something changed. If your system drive is small, six times the size of your index is the number to know.

That ceiling is per profile, not per PC. Each profile has its own index and its own backup folder, so each gets its own six. If you keep all three profiles, the worst case on your system drive is three times the figure above. It also means Settings › Backup only ever lists and restores copies belonging to the profile you have open — there is no way to restore one profile’s index into another, and no screen that shows you every copy on the machine at once.

Two more kinds are taken on top of those, and here we have to correct ourselves. PDR does take a copy of its own accord before certain actions — but only four of them. Three are in People: before Improve Recognition for one person, before Improve Recognition for everyone, and before sending a person back to Unnamed. The fourth is taken before a restore. No automatic copy is taken before a Fix run, before a rebuild or before an organizing pass. If you want a copy before one of those, you have to take it yourself, from Settings › Backup, where you can give it a name of up to sixty characters. The name is optional, and it is worth typing, because it is the only description of what is inside that copy you will ever get — it is kept in the file’s own name and nowhere else, so there is no record of how many photos a copy holds. Leave it blank and the copy is a size and a date.

Correction, 17 September 2026. This page listed re-clustering faces as a fourth People action that takes a copy first. It is not one. Changing the match threshold and re-clustering rewrites which faces are grouped together, and nothing is copied before it runs. If you are about to move that slider on a library you have spent time naming, take a copy by hand first from Settings › Backup.

The copy before a restore is the important one, and it is new. Restoring replaces your whole index, and picking the wrong row — two copies from the same day look much alike — used to cost you every face, name and tag added since that date, with no way back at all. The restore itself can now be undone. If that safety copy cannot be written, PDR stops and tells you rather than going ahead quietly, because you agreed to something undoable and that is no longer what it is. The copy shares the allowance for automatic copies rather than adding to it, so your backup folder does not grow.

PDR never deletes a copy you took by hand. It keeps two of those, and when you ask for a third it says so and asks you to delete one first, rather than quietly dropping your oldest — the one you saved on purpose is never the one the app decides to lose.

Those automatic copies also keep two, and the limit is applied when PDR starts as well as when a new copy is taken. That second half matters. The limit used to be ten, and it was only ever checked at the moment an eleventh was taken — so if you stopped using People, nothing aged them out. On our test machine ten of them, all made during a single afternoon in June, were still on the drive fifty-four days later occupying 3.3 GB, because no further People action had been run since. A backup folder can no longer sit oversized for months waiting for you to do something.

One more correction, and it is worth knowing if you have used PDR for a while. A copy left behind by an earlier restore used to be named differently from everything above, so PDR did not recognize its own file: it never appeared in Settings › Backup, no housekeeping removed it, and you could not delete it from inside the app — while its bytes were still counted in the space total PDR showed you. One permanent full copy of your index per restore, forever. Ours was 49 MB and seventy-one days old. That copy is now named by the same code that reads the list, so it appears like any other and is tidied away like any other. If you have an old one still sitting there, it is safe to delete, and the app will now let you.

Where they live matters more than it sounds. These copies are written to PDR’s own application-data folder on your system drive, not to your photo drive, so they are there whether or not your library drive is attached — including in the case described under files changed outside PDR, where starting PDR without the drive drops those entries from the index. Settings › Backup lists every copy and restores any one of them.

The date shown against each copy is the date the copy was taken, and you can use it. That has not always been true, and we said so here. Copies taken before a risky operation were always stamped correctly, but the copy taken at launch was made on the line before the database was opened, so the step that writes the library out and updates its time never ran — and on Windows copying a file carries the original’s modification time across with it. What you were shown was the last time your library changed, not the moment the copy was made. On our own machine six consecutive copies, created by five separate launches across three calendar days, were all listed under one identical date, one identical time and one identical size. A seventh was dated a day and a half before the launch that created it.

Fixed. That step now runs on its own connection to the database before the copy is made, and the result is checked afterwards rather than assumed. Re-measured against four real copies on 11 September 2026: three were exact to the second and the fourth was two seconds out. Naming a copy you take by hand is still worth doing, because a name says what the copy was for — but you no longer need it to work out when the copy was made.

Separately from all of that, PDR mirrors the index, the correction log and the most recent copies into a .pdr folder on the library drive when the drive is attached. This mirror is a portability feature and a safety net at once. PDR rewrites the mirror about every thirty seconds while you work, and it does so using the database’s own consistent-copy mechanism rather than a plain file copy, so it is a sound backup and not a snapshot of a half-written file. Restoring from it replaces your index wholesale, and the app’s own confirmation says what that means: your faces, names, dates and trees are back. Two conditions apply — it only exists if your library lives on an external drive or NAS you connected as your Library Drive, and restoring from it asks for your license key.

The limits, stated plainly. Restoring is a replace rather than a merge: the copy you choose becomes the index, so anything you did after it was taken is gone. The rebuild reconstructs the index from your files, so anything that only ever existed in the index and has no counterpart on disk is rebuilt by PDR rather than recovered. And because nothing checks the index for damage, PDR cannot tell you the index is broken.

You do not have to spot the problem yourself. PDR raises it on the dashboard. If it finds photos on disk that are missing from the index it offers Refresh now, and if the copy on your library drive holds substantially more than the index does it offers Restore now. What is fair to say is that both cards can be dismissed for good, and neither is a damage check — they notice a gap in the counts, not corruption.

Detaching your library drive does not leave you unprotected. The launch and pre-change copies described above are held on your system drive, not beside your library, so they are unaffected when the external drive is disconnected. Only the continuously rewritten mirror lives on the library drive. The same answer is recorded on our comparison table.

Seeing what is inside a backup before you restore it

It depends which of the three restore routes you are on, and the everyday one is the weakest. Restoring from Settings › Backup tells you the file name, when it was taken and how big it is, and warns you plainly that everything since then will be lost — but it does not tell you how many photos, albums or names are inside it. Size and date are your only clue, and the date is not reliable. The two recovery routes are better: both open the backup, count what is in it, and put those numbers in front of you before you agree to anything.

To do it

For an everyday restore, open Settings › Backup and read the date, size and any name you gave the snapshot. Use the name — it is the only description of contents that will ever exist for that copy. See rebuilding a damaged index.
If PDR notices the copy stored beside your library holds more than PDR is currently showing, it says so on the dashboard and gives you the two numbers — how many photos and album memberships the backup holds against how many are indexed now — before offering Restore now.
If you point PDR at a drive that already contains a library, the Existing PDR library found screen reports the database size, whether an edit history is present and which machine wrote to it last, before you press Restore from this library. It also shows a count of recent snapshots stored beside your library. That count used to always read zero, because the step that copied snapshots to the library drive looked for file names PDR never writes. It is fixed, and the figure is now real: expect up to two, the newest snapshot taken before a risky operation and the newest taken at launch. If it reads zero today, that is because no snapshot has reached the drive yet, not because the count is broken.

Limitations

The Settings list shows no counts at all. Not the backup’s, not the live library’s. Two snapshots of similar size are indistinguishable by content alone. The date beside each one is reliable — see rebuilding a damaged index — so you can tell when a copy was taken, but not what is inside it without naming it yourself.
Copies from older versions of PDR are recognized. The older naming scheme is understood, so those copies do appear in the list — shown as ordinary launch copies with no name against them.
You cannot browse a backup. There is no way to look inside one and pull out a single album, a single person or a single date correction. Restoring is all-or-nothing.
Name your manual snapshots. The name is the only thing that makes one recognizable later, and it is optional, so it is easy to end up with a list of dates that mean nothing.

Surviving a crash or a power cut

The library should survive; the last few moments of work might not. PDR runs its database in write-ahead logging mode, which is the arrangement that keeps a database consistent when the program dies unexpectedly. Referential integrity is enforced rather than assumed.

Corrected 17 September 2026. This paragraph used to say that PDR settles the write-ahead log properly when it shuts down, so that a clean quit left nothing dangling. We cannot show you that it does. There is no step anywhere in PDR’s shutdown that settles the log — the database is simply closed — and on the machine we test against a write-ahead file is sitting beside the index right now, with PDR not running, holding twenty kilobytes of work. We first noticed this on 29 July 2026 and found it again unchanged on 17 September. It does not put your library at risk, because reopening PDR folds that file back into the index and nothing is lost, and it no longer costs you anything on the safety copy either — as the end of this section explains, the copy now settles the log itself before it reads a byte. We are correcting it because we stated it as a fact about the product and it was not one.

If PDR itself crashes — the application quits, the machine keeps running — the index should be intact when you reopen it, with everything committed up to the crash.

A power cut is a weaker story and we would rather say so than let you assume otherwise. PDR runs the database at a durability setting that does not force the operating system to flush every change to the disk platter immediately. That choice buys a great deal of speed while indexing tens of thousands of files, and it does not risk corrupting the database. What it does risk is losing the most recent committed changes when the power goes rather than the program. In practice: the library is fine, the last handful of things you did may be gone.

We have not published a figure for how much can be lost, because it depends on your disk and your operating system, and we have not measured it. Rather than guess, we are telling you the setting and its consequence.

Two interruptions that are easy to get wrong are handled deliberately. Restoring an earlier copy of the index clears the database’s pending write-ahead files as part of the restore; without that step the old pending writes can be replayed over the copy you just restored and quietly undo it. And the startup pass that can remove index entries takes a copy of the index before it touches a single row, so an interrupted or misbehaving tidy-up leaves the previous state recoverable from Settings › Backup.

Corrected 17 September 2026, in your favor. We used to warn you here that the copy was taken before the database was opened and captured the main index file only, not the pending write-ahead file beside it — so that the copy taken on the first restart after a crash would be behind by whatever the crash left pending. That was true of the old copy routine and it is not true of this one. Before it reads a byte, PDR now takes the database’s own write lock, folds the pending write-ahead file into the index, and confirms it actually emptied; only then does it copy. If any of that declines it falls back to the database engine’s own snapshot command, and if that fails too it writes no copy and tells you why, because a copy nobody can vouch for is worse than a missing one. You can see the result on disk: the write-ahead file beside your live index has bytes in it, and the one beside each saved copy is empty, because the copy was taken with nothing left pending. The first restart after a crash is no longer a bad moment to reach for a copy.

Taking your settings somewhere else

You cannot. Version 3.0.11 has no export and no import of settings, folder rules, naming schemes or presets of any kind. There is no file to copy and no menu item to look for. Moving to a new computer means setting PDR up again by hand.

This is a straightforward missing feature, not a considered position. It is on the list.

One clarification so the boundary is honest, because it is easy to confuse the two. Your index can travel: PDR keeps a copy alongside your library so that a library moved to a new machine can be picked up rather than rebuilt from nothing. That mechanism is described on the restoring page, and it is about the library. It does nothing for your preferences, which stay behind.

When files change outside PDR

This is the most important section on the page, and the one most likely to surprise you.

PDR notices files that have disappeared. It does not notice files that have changed. Each time it starts, PDR walks every entry in its index and checks whether that file is still where it was. What it never does is compare modification times or contents, so a photo that another program has edited, rotated or re-saved looks completely unchanged to PDR. The index quietly goes stale and nothing says so.

For files that have gone, the behavior is still silent. PDR does not report them and ask you what to do — it removes them from the index, with no prompt and no summary.

What it no longer does is confuse an unplugged drive with a deletion. This is the change in 3.0.8, and it was the single worst thing on this page. PDR now records each drive’s own serial number alongside the photos it indexed there, and on startup it works out, drive by drive, which of five things it is looking at: the same drive on the same letter, in which case it tidies up as before; the same drive on a different letter, in which case it rewrites the paths and then tidies up; a different drive answering on that letter; nothing there at all; or a drive it has never seen, which it records and leaves alone this time. Only the first two are ever tidied. Start PDR with your photo drive unplugged and nothing is removed — those photos are simply not searchable until the drive is back, and then they are, with everything PDR knew about them intact.

The same applies when Windows gives the drive a new letter. That used to look exactly like a deletion of every photo on it and cost a full rebuild; now the paths are rewritten and the index carries on.

A rebuild is therefore a rare thing rather than a routine hazard — but it is worth knowing what one costs, because deleting photos from a drive that is connected still removes them from the index silently. Face matches, AI tags and album membership hang off the index entries, so they are cleared along with them and a rebuild cannot put them back — it finds the files again, not the knowledge. Your named people and your albums still exist; which photos they contain does not. So the rebuild is the recovery of last resort here, not the tidy answer we implied. If you have a copy of the index from a launch when the drive was attached, restore that instead: see rebuilding a damaged index.

The safest habit is simply to attach the drive before you open PDR. We would rather tell you that than have you discover it. If it has already happened, you have two ways back: reattach the drive and rebuild, or — better — restore the copy of the index taken at the previous launch from Settings › Backup, which is the route that keeps the face matches and album membership. See rebuilding a damaged index. The underlying behavior is listed in known gaps, and our own view is that entries for a drive that is merely absent should be marked unavailable rather than removed.

A record of what was changed, and when

In 3.0.11 there is no such record.

PDR contains the machinery for one: a routine that appends every date correction to date-corrections.log.jsonl in its application-data folder, one line per correction, stamped with the time. It is append-only by design, so entries could never be quietly rewritten. Alongside it sits an undo for the last correction.

None of it runs. The routine is only reached from a code path that no control in the application calls, so the log file is never created and the undo beside it never fires. There is no history panel, no log viewer, and no file to open even if you went looking for it. The machinery was built and never connected.

What you do get is narrower and lives elsewhere: the Undo panel in Needs dates, which reverses the last batch of dates you set for about a minute after you set it, and the library copies taken at each launch, which let you go back to how the library looked at a point in time. Neither is a per-change history.

We have graded this “no” on the comparison table for that reason. Connecting the log and giving it a viewer is on the list below.

Reversing a whole batch of saved date corrections

Yes, for about a minute. When you set a date on a selection in Needs dates, it is written to your library straight away — there is no staging step. A small panel then appears at the top of the view reading Saved N files, with an Undo next to it. Press it and every file in that batch goes back to the date, source and confidence it had before, and returns to the Needs dates list. The panel disappears roughly sixty seconds after the save, and once it has gone there is no other control that takes the batch back.

To do it

Open Needs dates, select the files that share a date, and set it.
If any of them already had a date, PDR asks you to confirm before replacing it.
Read the Saved N files panel at the top of the view. If the batch is wrong, press Undo while it is still showing.
If the panel has gone and you still want the batch reversed, open Settings › Backup and restore a copy taken before you started — accepting what else that costs you. See rebuilding a damaged index.

Limitations

The undo covers the last save only. Save a second batch and the first one is no longer reachable, however recent it was.
It expires on a timer, not on your attention. Roughly sixty seconds after the save the panel dismisses itself. Leaving the view or dismissing the panel by hand ends it early.
There is no history of saves. No list, no log viewer, nothing that shows you which batches you set last week.
Restoring a copy is not selective. The copy you choose becomes the library, so every album, name and correction made after it was taken goes with the batch you were trying to remove. There is no way to lift out one batch and keep the rest.
Nothing here touches your files. Setting a date in Needs dates changes PDR’s record of the photo. It does not rename the file and it does not write the date inside it — so undoing has nothing to unwrite. See a record of what was changed, and when.

Opening the same portable library from two computers

No. You are told, and you are not stopped. A library kept on a portable drive records which machine currently holds write access to it, and a second computer that opens it is labeled read-only and shown a message saying another device holds write access. That is where it ends. The label is advice, not a lock. The only operation actually refused on the second machine is the manual mirror-to-drive; a Fix run, a date correction and every other write go through exactly as they would on the first machine. So two computers can write to one portable library, which is the thing this question asks to be prevented. When the computer in front of you is the one that should be working, you confirm your license key and the recorded claim moves to it — but you never needed to.

3.0.9 closes the worst version of this. If a drive already holds a library that another computer still claims, Set as new library is now refused outright and PDR names the computer holding it. That path used to take write control without asking and then put this computer’s library up over the one that was already there — the other machine’s library, replaced, with nothing said. It is the only refusal that has been added. Connect to a library you already have is unchanged, and deliberately so: that is how you move your library to a new PC when the old one is sold, replaced or has died. Once you are connected, everything in the paragraph above still applies.

To do it

Connect the drive to the second computer and open the library as you normally would.
Read the message, and take it as a warning rather than a guarantee. Browsing, searching and viewing all work — and so, for now, does everything else.
To make it official, confirm your license key when PDR asks. The recorded claim transfers to the computer in front of you.
Until the lock is enforced, do the safe thing yourself: close the library on the first machine before you write to it on the second.

Limitations

Nothing enforces it. This is the limitation that matters and we previously wrote the opposite. As of 3.0.11 exactly two things are refused: the manual mirror-to-drive on a read-only device, and setting up a drive another computer claims as a new Library Drive. Both guard setup and backup. No ordinary write consults the claim — a Fix run, a date correction, a name, an album all go through on the second machine — so the protection this section is about still does not exist.
It is a recorded claim, not a lease. There is no timeout and no heartbeat, so nothing expires the claim on its own. If the machine that holds it crashed, was sold or has died, the claim simply stays where it is until another machine takes it over.
Taking over needs a valid license key. That is what stops a stranger who finds your drive from claiming your library — but it also means someone whose trial has ended cannot take their own library back from a dead PC without buying one first.
Nothing on screen tells you the marker is there. It lives in a hidden folder at the top of the library, so most people meet it for the first time as a refusal rather than as a setting they knew about.
The read-only machine does not mirror anything back. Changes cannot be made there, so there is nothing waiting to be merged when access moves — see repeating backups to a second drive.

Known gaps

These are the specific shortcomings behind the answers above, written down so that a reader comparing products is not relying on our marketing. They are open items, not fixed ones.

No integrity check. PDR never verifies its own index and cannot warn you that it is damaged.
The startup tidy-up removes rather than reports. Index entries for files it cannot see are deleted outright, with no prompt and no summary shown to you.
The tidy-up gives you no record of what it removed. It no longer mistakes an unplugged drive for a deletion — that was fixed in 3.0.8 — but on a drive that is present, files that have genuinely gone are dropped with no prompt and no list afterwards.
Restoring an earlier copy of the index is a replace, not a merge. The copy you choose becomes the index, so anything you did after it was taken is lost. There is no way to recover one folder, one person or one album from a copy while keeping the rest.
Modified files are not detected. Nothing compares timestamps or contents, so edits made in other programs leave the index silently out of date.
The audit log is never written. The routine that would record every date correction sits in the application unconnected, so the log file is never created and there is nothing to view.
Setting a date by hand does not write it into the photo. A date you set in Needs dates updates PDR’s record only — the file is not renamed and its own metadata is untouched, so nothing outside PDR sees the correction until you Fix those files into a destination.
The read-only marker on a second computer is not enforced. 3.0.11 refuses two things — the manual mirror, and setting up a drive another computer claims as a new Library Drive — but every ordinary write still proceeds, so two machines can write to one portable library.
A rebuild loses face matches, AI tags and album membership. They are attached to index entries and are cleared with them, and the rebuild finds files rather than restoring what was known about them.
Nothing takes a copy before a Fix run, a rebuild or an organizing pass. Automatic copies are taken at launch, before three actions in People, and before a restore. Re-clustering faces is not one of them.
No settings export or import of any kind.
A Fix run always produces a second copy. There is no sidecar or database-only mode, so you cannot ask PDR to record a correction without writing a new file. Correcting a large library costs the disk space of a second copy of it.

One gap has come off this list: editing a caption no longer touches the photograph’s date. Until 3.0.9 this page warned that captioning a photo could overwrite its original date with the file’s modification time. It was worse than “could”: the caption box in the Viewer wrote the date every time, so a photograph taken in 1998 came back stamped with today. In 3.0.9 a caption writes the caption and nothing else, and there is a test that fails if that ever changes. If you captioned photos on an earlier version, their dates inside PDR are unaffected — it is the date stored in the file itself that was rewritten, and a Fix is what puts a corrected date back into a file.

How to check any of this yourself

Nothing on this page asks you to take our word for it.

That corrections never touch the original: note a photo’s file size and modification time, run a Fix on it, and look at the source again. Both are unchanged, the filename is unchanged, and the corrected version is a separate file in the library folder you chose.
That indexing does not write: add a folder of photos, let it index, and compare modification times before and after. They will not have moved.
That an unplugged drive is no longer emptied from the index: index a folder on a removable drive, close PDR, detach the drive, and start PDR again. Reattach it and reopen PDR without rebuilding anything. The photos are back, and so are the albums and named people they belonged to.
That the second computer is not actually stopped: open a portable library on a second machine, read the read-only message, and then run a Fix anyway. It will run.
That the backup dates are unreliable: open PDR three times in one morning, then look at Settings › Backup. Copies from three different launches will be listed under the same date and the same size.
That the audit log is not there: make every date change you can, then open PDR’s application-data folder and look for date-corrections.log.jsonl. There is no such file. The routine that would write it is never called by anything in the application.
That there is no settings export: look through Settings. There is no export, and no file to find.

Every answer on this page was checked against the shipping 3.0.11 build, not against the source code. Confirming that a mechanism exists is not the same as confirming what it does, so each claim here was run on an installed copy with real photos and the result recorded. Where the result was worse than we expected, the answer on this page and the matching answer on our comparison table both say so.

If you find any statement on this page to be wrong on the shipping 3.0.11 build, tell us and we will correct the page. That offer is the whole basis on which we ask you to trust the comparison.