pnp
Bug report: Version history/metadata not preserved when copying files using SPO file copy command
Priority
(Urgent) I can't use the CLI
Description
When using the m365 spo file copy command to copy files between SharePoint locations, the version history and associated metadata of the file are not preserved in the destination location.
Steps to reproduce
-
Have a source file with version history in SharePoint Online
-
Run the following command:m365 spo file copy --webUrl https://contoso.sharepoint.com/sites/project --sourceUrl /sites/project/Customer2/Product-Catalog.pdf --targetUrl /sites/project/Customer1
-
Check the copied file in the target location
Expected results
The file should be copied with its complete version history and metadata preserved.
Actual results
The file is copied successfully, but while the version number (e.g., "8.0") is preserved, the version history details and associated metadata from the source file are lost. The version information in the target shows the correct version number, but the history of changes and previous versions are not accessible.
I also tried using the parameter --ignoreVersionHistory false but it did not improve the situation. The detailed version history was still not preserved.
Both source and target document libraries have identical metadata fields, and there are no required fields that would prevent successful metadata migration.
Diagnostics
{ "CheckInComment": "", "CheckOutType": 2, "ContentTag": "{308A6B11-5245-423E-9273-98529969046A},9,1", "CustomizedPageStatus": 0, "ETag": ""{308A6B11-5245-423E-9273-98529969046A},9"", "Exists": true, "ExistsAllowThrowForPolicyFailures": true, "ExistsWithException": true, "IrmEnabled": false, "Length": "1285533", "Level": 1, "LinkingUri": null, "LinkingUrl": "", "MajorVersion": 8, "MinorVersion": 0, "Name": "Product-Catalog.pdf", "ServerRelativeUrl": "/sites/project/Customer1/Product-Catalog.pdf", "TimeCreated": "2025-05-05T12:02:55Z", "TimeLastModified": "2025-05-05T12:02:55Z", "Title": "Product Catalog Modified Ver 3", "UIVersion": 4096, "UIVersionLabel": "8.0", "UniqueId": "308a6b11-5245-423e-9273-98529969046a" }
CLI for Microsoft 365 version
v10.5.0
nodejs version
v20.11.1
Operating system (environment)
Windows
Shell
PowerShell
cli doctor
No response
Additional Info
This is important functionality for migration scenarios where preserving the complete history of document changes is required.
Thanks for logging this issue @webmastergott.
Unfortunately, it seems like this is not an issue from our end. We are limited by the functionalities that SharePoint APIs are giving us. In this case, it seems like when you copy a file to the same library, the history looks identical, but if you copy it to another library or site collection, you get the behavior that is described by you. It seems like this is how the SharePoint API works. I don't know whether it was made intentionally like this, but it's not something we can fix from our end.
@milanholemans I had a quick check on a test case I created just now and it seems in my case it worked properly and I cannot reproduce this error🤔 source lib
target lib
the command I did execute:
m365 spo file copy --webUrl https://tenanttocheck.sharepoint.com/sites/PnPDemo --sourceUrl "/testB/Document.docx" --targetUrl "/sites/PnPDemo2/testB"
Although my case is a bit simpler, only single column and all modified the same day, but still it seems that it should be working properly.
But I do agree that this is not some custom logic/magic we are doing under the hood here. In this specific command we are just executing _api/Site/CreateCopyJobs and it should 'just' do its work 🤔.
On the other hand one option we could try to explore is by setting MoveButKeepSource. If we check the docs for this API we will find that when doing move and settings MoveButKeepSource "The file will move to destination, but the source content will not be deleted..." and that "This is not like the normal copy, which only copies the most recent major version and doesn't maintain all the metadata."
I wonder if we would expose this param as an option in the spo move command and would the result be same, so will actually copy the file not move, and maybe it would also properly behave in terms of keeping file history 🤔
@milanholemans I checked with pdf file and still I am unable to reproduce this error. On my end it is working fine
@pnp/cli-for-microsoft-365-maintainers maybe you will have any luck?
also @milanholemans what do you think if we extend the spo file move with MoveButKeepSource option so we will have a move with copy kind of option which may solve this issue 🤔.
@milanholemans I checked with pdf file and still I am unable to reproduce this error. On my end it is working fine
@pnp/cli-for-microsoft-365-maintainers maybe you will have any luck?
also @milanholemans what do you think if we extend the
spo file movewithMoveButKeepSourceoption so we will have amovewithcopykind of option which may solve this issue 🤔.
Weird, I managed to reproduce it on my tenant as well. We can investigate the MoveButKeepSource option. Are you sure it works using that?
Weird, I managed to reproduce it on my tenant as well. We can investigate the MoveButKeepSource option. Are you sure it works using that?
Did you had more complex case? Maybe it just happens on 'some' tenants.
About MoveButKeepSource - totally no idea if it works, it is only some observations I found when checking the docs. This is something we could investigate and confirm. It would be best to prototype this solution locally, add this option to the move command and check when set if it will solve this problem, but since I cannot reproduce this on my tenant I have no chance of testing the POC.
Did you had more complex case? Maybe it just happens on 'some' tenants.
Not a complex case at all. Just took a PDF file in my tenant, and created the same column in 2 libraries (managed metadata) on the same site collection.
Source file:
Copied file: