Differences

This shows you the differences between two versions of the page.

--- software:squirrel:version_history [2026/01/10 16:54] – support@smikar.com
+++ software:squirrel:version_history [2026/02/13 14:34] (current) – support@smikar.com
@@ Line 3: / Line 3: @@
 This page explains how **version history is handled by Squirrel** when files are archived and later restored back into SharePoint.
-It is intended for customer administrators who need to understand how historical versions, authorship, and timestamps behave during the archive and rehydration lifecycle.
+It is intended to explain how historical versions, authorship, and timestamps behave during the archive and rehydration lifecycle.
 ----
@@ Line 9: / Line 9: @@
 ==== 🎯 Overview ====
-When Squirrel archives a file, the file and its available SharePoint versions are stored securely in Azure Blob Storage. When a user restores a file via a stub, Squirrel rebuilds the version chain in SharePoint so that the file can continue to function as a normal SharePoint document.
+When Squirrel archives a file, the file and its available SharePoint versions are stored securely in Azure Blob Storage. When a file is restored, Squirrel rebuilds the version chain in SharePoint so that the file can continue to function as a normal SharePoint document.
 The restore process is designed to preserve version history and associated metadata as closely as possible, while operating within the constraints of Microsoft 365 and SharePoint’s versioning model.
@@ Line 23: / Line 23: @@
   * File content is written back into SharePoint.
   * Version-level metadata such as author and modified timestamps are applied where supported.
-The objective is to reconstruct the version chain so that historical changes remain visible and traceable inside SharePoint.
 ----
@@ Line 38: / Line 36: @@
   * Version ordering
   * File-level metadata
+  * Content Status
 Where the original user account exists in Microsoft Entra ID and can be resolved, SharePoint will normally display the original author information. If SharePoint cannot resolve the account, it may automatically fall back to a system identity.
+If the original author cannot be located within Microsoft Entra ID, the version will be stamped using the SharePoint system account.
 Because this behaviour is ultimately controlled by Microsoft 365, exact stamping results may vary in some environments.
+----
+==== 🕒 Timestamps, Dates, and Timezones ====
+During restore, Squirrel attempts to apply original created and modified timestamps back onto files and versions where supported.
+Because SharePoint and Microsoft 365 store and display timestamps using internal UTC values and tenant or user locale settings, administrators may observe minor differences in how dates and times appear before and after a restore.
+These differences can include:
+  * Time values appearing shifted due to timezone or regional settings.
+  * Display formatting differences in SharePoint views or version history.
+  * System-generated timestamps associated with the restore operation itself.
+The restore process does not rewrite historical events, but timestamp presentation and final write operations remain subject to Microsoft 365 platform behaviour.
 ----
@@ Line 65: / Line 82: @@
 ----
-==== 🧩 Minor Versions and Why History May Appear to Shift ====
+==== 🧩 Version Handling During Restore ====
-SharePoint supports both **major** and **minor** versions. Minor versions are often hidden in the user interface, but they still exist internally.
+Squirrel captures and restores both **major** and **minor** versions, preserving the original version structure.
-If the most recent change to a file before archiving was a minor version, the following can occur during restore:
+  * Minor versions are restored as minor versions.
+  * Major versions are restored as major versions.
+  * The original version numbers are preserved (e.g., 0.1, 0.2, 1.0, 1.1, 2.0).
+  * Original authors are preserved (assuming the user account still exists in the tenant).
+  * Version comments and dates are preserved.
-  * SharePoint rebuilds the historical version chain.
+**Note:** In libraries with minor versioning enabled, the "Modified By" field on published major versions may show the service account instead of the original user. The original author is preserved in the version comment.
-  * The previously hidden final minor version becomes visible.
-  * SharePoint writes the restored file back as a new current version on top.
-This results in:
-  * A new visible top version representing the restored file.
-  * The previously hidden minor version appearing directly below it.
-This can make it look as though version numbers or authors have shifted, when in fact the historical change already existed and has simply become visible.
-The underlying history is not rewritten. The restore process exposes the previously hidden version and adds a new current version above it.
 ----
-==== 🔍 What Administrators Should Expect ====
+==== 🔍 Following a restore ====
-After a restore, administrators may observe:
+After a restore, the following may be observed:
   * A newly created top version representing the restored file.
@@ Line 94: / Line 104: @@
   * Previously hidden minor versions becoming visible.
   * Version timestamps and authors populated where supported by SharePoint.
-This is normal SharePoint behaviour when a file is programmatically rebuilt and does not indicate loss of history.
 ----