Fixed.

The cause was in how the project folder itself was recorded. When a project path still contained '..' steps in the middle of it, those steps were mistaken for ordinary folder names while working out where each file lived. Every reference derived from that path then pointed several levels too high - eventually above the drive itself, which is why the files could no longer be found. Project paths are now resolved to a single plain form before anything is derived from them.

Two further points follow from this:

• Deciding whether a file sits in the project folder was a comparison of the written-out paths, so a file right next to the project could be judged as being somewhere else and needlessly given a shortcut. That decision is now made on the folder itself, so files stored with the project are simply referred to by name and no shortcuts are created.

• A shortcut that could not be followed was kept on as if it were the file, so saving added another '.lnk' to the name each time. When a shortcut cannot be found and a file of that name sits in the project folder, that file is now used instead and the redundant shortcut is cleaned up on the next save. This is the normal situation for a project folder that has been copied or moved as a whole.

Existing affected projects repair themselves on opening: the references are corrected, the project is marked as changed, and saving writes the corrected project file. Projects that legitimately refer to files in other folders keep working as before - in particular, a file on a network location that is temporarily unavailable is left untouched rather than being swapped for a same-named local file.