Forum Discussion
Solved
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
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.
- 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?
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
Norman Youngthank you for looking into this. I have some more information to add:
If you map a network drive to sharepoint I found everything appears to work correctly from there. Specifically:
a) copying a file from another library to the controlled library (both using file explorer windows) will say 'no' if it isn't checked out or create a new version if it is checked out and you 'over write'.
b) copying from another library using file explorer and dragging to edge window with controlled library will also create a new version when you over write a checked out file
also interestingly:
a) in the mapped drive in file explorer you can rename a file in a controlled library without checking it out
b) you can right click (or ctrl click) to copy a file you are dragging (in edge it will only move the file using the click and drag)
c) a down side to using the mapped drive in file explorer appears to be the inability to check out/ check in documents (although you are prompted when you open documents and such)
