Forum Discussion
versioning fails when copying
I apologize if this is answered elsewhere but I couldn't find it.
So we have multiple libraries of which 1 is 'controlled' and has versioning turned on. I am trying to use the versioning to maintain released file history.
When I have a file in the controlled library that I want to update I can download it, work on it and when ready to 'release' it I check it out from the library, upload the new version (overwrite the existing with the new version), and check it back in. That seems to work and I can add in the comment field the new Rev #/letter and such.
But if I have the updated file in a different sharepoint library (a working library) and I copy it to the controlled library, it again prompts if I want to overwrite, but in that case I lose the prior history of the controlled file (it is completely wiped out and only the new copy exists).
I know that 'copying' a file only copies the most current version of that file, but I'm not sure why the 2 different methods of 'over-writing' a new version of a controlled file should act so differently. I know that the 'proper' method is to check out and replace the contents of the file and check in, but that doesn't work so well with pdf files and such.
ALSO, but similar, when I upload to the controlled library the file new or changed file is checked out and must be checked in (which is good so I can add the Rev info and such), but when I copy from another library to the controlled library the new (or overwritten) file is NOT checked out and hence I do not have an opportunity to make a comment on the check in process.
Am I missing something, or is this how it is supposed to work?
Hi mtarler,
I thought a custom permission level would work but it did not. I could not find a site, document library or versioning setting that would help either.
This is not ideal, but you can create a trigger to notify you when a file is deleted using Power Automate. This will provide an opportunity to intervene and restore the file (and version history) from the site recycle bin.
I hope this helps.
Norm
Hi - mtarler - I don't have an answer, just more details that my team figured out recently.
Like you said, if you drag and drop a file into a library, you'll be adding a version (if a file with the same name exists).
However, if you use the Move or Copy feature to move/copy a file from another SharePoint/OneDrive library, then it'll completely replace the existing file, including the version history.
If you use the Move or Copy feature when there is no existing file in the destination, the Move feature will bring the version history but the Copy feature won't.
Before we tested all of this, we assumed that copying a file would simply add a new version (like uploading a file) but that's not the case and it feels like a bug to us (poor user experience at best).
Hello mtarler and Deleted,
This is interesting behavior and not what I would have expected. I've reached out to others for confirmation of the behavior. I will follow up when I hear back
I hope this helps.
Norm
Turns out this behaviour is by design.
When you use Copy to with documents that have version history, only the latest version is copied. To copy earlier versions, you need to restore and copy each one.
More information on the Copy files and folders between OneDrive and SharePoint sites site.
Thanks to Susan Hanley for pointing us to the official answer.
I hope this helps.
Norm
- Just to add to this ridiculous behavior, if you use Teams and add a cloud storage to be able to copy/move files from your team site to another SharePoint site, you will see that copying from your teams site to the cloud storage will add as a new version if the file already exist!!! Inconsistency seems to be a functional rule at Microsoft... Note that this will all go away in Teams when the new copy / move dialog will be deployed as it does not display your cloud storage as a destination... Very tired of all this mess.
Totally agree. We want to implement a document management system with version history and this behaviour completely threatens to undermine all of the security we have built into our controlled libraries. We should not have to depend on staff understanding that 'replace' means different things depending on if you are uploading or copying - especially as this does not appear to be documented - and we found it out by accident during testing. Another serious problem we ahve found is that copying a document with the same name from another site completely overrides a document in a check out to edit library even when it is not checked out - whole history gone!
- How do we get Microsoft to address this now that uservoice has gone?
We also have this issue and it is of concern because it is used for audit and it does not replicate on premises copy using the file explorer (how users used to work). Copy To does not leave the previous history in the Copy To destination and also set the version being copied to be the Latest version. It deleted the entire file and replaces with a single version copy, which is not how it should work. In my opinion this is a straight forward bug, not inconsistent functionality and should be fixed.
