Cloud Storage Changed Your File Dates or Metadata? Separate File Contents From Filesystem Metadata First

Short answer: a cloud upload can preserve the file contents perfectly while still changing the way the file looks to the local filesystem after a later download. Date created, Date modified, Unix permissions, NTFS ACLs, Finder tags, extended attributes, cloud sharing permissions and EXIF metadata are not one thing. They live in different metadata layers, and no sensible migration plan should assume they all round-trip identically across Windows, macOS, Linux and five different cloud platforms.

That is why a migration can pass a checksum test and still fail an archive-preservation test.

The most important mental model is this:

Bit-for-bit file integrity and metadata fidelity are separate verification jobs.

If a 20-year photo archive, legal-document repository, source-code tree or research dataset depends on dates, ownership or filesystem attributes, checking only that the files open is not enough.

The four metadata layers people accidentally mix together

Before comparing providers, separate the metadata into four layers.

This explains several otherwise confusing incidents.

A downloaded JPEG can have a new Windows Date created but still contain the original 2012 EXIF DateTimeOriginal. A file can preserve its local modified time but lose the original cloud sharing permissions when copied to another account. A Mac file can have identical bytes but lose a Finder tag or unsupported extended attribute on a round trip through a service that does not preserve that attribute.

If your first concern is whether the bytes themselves survived the upload, solve that separately with a checksum workflow. For the broader distinction between synchronized storage and an independent recovery copy, see Cloud Backup vs Cloud Storage.

Created time is the easiest timestamp to misunderstand

Created sounds like an intrinsic property of a document. It often is not.

At the filesystem layer, a creation or birth timestamp commonly describes when this filesystem object was created on this particular filesystem. Copying a file to a different disk, downloading it through a browser, extracting it from an archive, or recreating it through an API can legitimately create a new filesystem object and therefore a new local creation time.

That does not necessarily mean the file's historical content date was lost.

For photos, the date that usually matters for archival chronology is the embedded EXIF capture timestamp, not the filesystem creation date. For documents, the relevant historical date may be an application-level metadata field, a document-management record, or a separate manifest.

So if you migrate a photo library and Finder or File Explorer suddenly says every file was "created today," do not immediately conclude that every original timestamp is gone. First determine which timestamp changed.

Modified time is more portable — but still not universal

Modified time is generally more useful for detecting working-file changes, but even this can depend on the transfer path.

Dropbox documents a particularly clear example. Its current help page says the desktop app can preserve a file's modified date during upload and download. The same page warns that a file uploaded or downloaded through dropbox.com or a mobile device does not preserve that modified date in the same way. Dropbox also says that manually changing only the local modified timestamp, without changing file contents, does not propagate that timestamp change to every device.

That gives us a practical rule:

Provider + transfer method matters. “I used Dropbox” is not enough information.

The same archive can produce different local timestamp results depending on whether you used a desktop sync client, browser download, API migration or a third-party transfer tool.

Dropbox additionally documents support for some extended attributes. That is useful, but the word some matters. It is not a promise that every platform-specific attribute, ACL or filesystem feature is portable to every other system.

Google Drive has rich cloud metadata, but that is not the same as cloning a filesystem

Google Drive's API exposes substantial metadata for a file. Current documentation includes fields such as:

• createdTime;
• modifiedTime;
• originalFilename for binary content;
• checksums for stored binary files;
• permissions and capabilities;
• extracted image and video metadata in relevant cases.

Google also explicitly describes Drive metadata as data such as a file's name, type, creation time and modification time. For image and video files, Drive can expose metadata extracted from EXIF and other embedded metadata.

What this does not prove is that an arbitrary local filesystem's entire metadata model is being cloned into Drive and perfectly restored onto another filesystem.

A Google Drive permission is a cloud ACL describing who may read, write or organize the Drive object. That is not the same data structure as a Unix owner/group/mode tuple or a Windows NTFS ACL. Likewise, an extracted EXIF field shown by Drive is not the same thing as preserving every local extended attribute attached to the file on macOS.

This is the distinction migration tools often hide behind a generic word like metadata.

Do not compare two different timestamps as if they were the same field

A cloud service can have a server-side created time for the object and your downloaded file can have a separate local filesystem creation time. Both can be accurate descriptions of different events.

If you need legal or archival provenance, decide in advance which event you are trying to preserve.

OneDrive explicitly separates service timestamps from client filesystem timestamps

Microsoft Graph provides one of the clearest technical demonstrations of this problem.

A OneDrive driveItem has service-level fields including createdDateTime and lastModifiedDateTime. Microsoft also exposes a separate fileSystemInfo facet containing the created and modified timestamps reported by the local client filesystem.

Microsoft's own example is revealing:

• a file is created locally on Monday;
• it is uploaded to OneDrive on Tuesday;
• the OneDrive item can have a service creation time reflecting Tuesday;
• fileSystemInfo.createdDateTime can preserve the client-reported Monday value if the uploader supplies it.

That is exactly why one generic column called "Created" is not enough for a migration audit.

Microsoft also warns that copying files between a work/school OneDrive and a personal OneDrive makes them new items. Its current transfer documentation states that those copied files do not retain some metadata such as Date created or Modified By, and sharing has to be recreated.

So if you are moving data between OneDrive accounts, do not assume that because the filenames and bytes arrived, the cloud-object history and collaboration metadata arrived too.

iCloud and Apple's File Provider show why extended attributes need their own audit

Apple's File Provider framework makes another important boundary visible.

Apple documents that File Provider can synchronize extended attributes, but the system decides which attributes are syncable. Apple also caps syncable extended attributes at roughly 32 KiB total per item; attributes beyond that can become nonsyncable. Apple separately models metadata such as Finder-related information, tags and filesystem flags.

That tells you something useful even before discussing one specific iCloud Drive workflow:

Extended attributes are not an unlimited opaque blob that you should assume every cloud round trip preserves.

For a normal user moving PDFs and JPEGs, this may not matter. For Mac workflows that depend on Finder tags, resource forks, application-specific xattrs or filesystem security metadata, it can matter a great deal.

CloudScope will not turn Apple's File Provider documentation into a blanket claim that "iCloud Drive preserves every xattr." The documentation itself says the system decides which attributes are syncable and applies limits.

If metadata-sensitive Mac files are valuable, test the exact file type and attributes you depend on before removing the original volume.

pCloud exposes created and modified times — and its API lets an uploader set them

pCloud's official API is unusually explicit about timestamp control.

The stat method returns file metadata including created and modified. More importantly for migrations, the uploadfile method accepts optional mtime and ctime parameters. copyfile also supports setting mtime and ctime on the resulting copy.

That means a developer or migration tool can deliberately carry timestamp values into pCloud instead of accepting only the upload time as the new metadata state.

This is a real capability, but it needs a precise boundary:

• it proves pCloud's API supports explicit created/modified timestamp values;
• it does not prove that every desktop copy path preserves every local ACL, xattr, Finder tag or Windows security descriptor;
• it does not make a pCloud file a byte-for-byte clone of an NTFS, APFS or ext4 inode.

If you are building a migration pipeline, that API-level timestamp control is useful. If you are simply dragging folders through a desktop UI, verify the resulting timestamps instead of assuming the API capability describes every client path.

Permissions are even less portable than timestamps

This is where migrations become dangerous.

There are at least three permission systems that people casually call "permissions":

1. local filesystem permissions — for example NTFS ACLs or Unix owner/group/mode;
2. cloud sharing permissions — who can view, comment, edit or manage the cloud object;
3. application permissions — access controlled inside a document-management or collaboration system.

These systems are not interchangeable.

Copying a folder from a Linux server into consumer cloud storage does not mean its UID, GID and mode bits become meaningful cloud sharing rules. Downloading a Google Drive folder does not mean its Drive ACL should become a Windows NTFS ACL. Moving files between OneDrive accounts can require re-sharing even when the file contents themselves copy successfully.

For a team migration, therefore, do not ask only:

Did all 100,000 files arrive?

Also ask:

Which access-control model is authoritative after the migration?

If permissions are business-critical, export or inventory them separately and rebuild them deliberately in the destination system.

Why photo libraries are a classic metadata trap

A photo archive commonly contains at least three dates:

• filesystem created date;
• filesystem modified date;
• embedded EXIF capture date.

A migration can change the first one, preserve the second one, and leave the EXIF date untouched.

If a photo manager sorts by EXIF capture time, everything may still look correct. If a crude folder script sorts by filesystem creation date, the same archive can suddenly look as if every photograph was taken on migration day.

That is not a small cosmetic problem if the archive has tens of thousands of files.

Before migrating a photo or video archive:

1. identify the field your downstream software actually uses;
2. export a metadata sample before the move;
3. perform the move with a representative test set;
4. compare embedded metadata and filesystem timestamps separately;
5. only then scale the migration.

If the real question is whether the original photo/video bytes are preserved rather than how their dates are represented, treat that as a separate verification problem. A low-quality browser preview does not prove the stored original was altered.

A checksum cannot detect a lost Finder tag or changed creation time

This deserves repeating because technically sophisticated users can still make this mistake.

Suppose these two files have identical SHA-256 hashes:

source/photo.raw downloaded/photo.raw

That proves the file contents are identical for practical integrity verification.

It does not prove that these are identical:

• local creation timestamp;
• local modification timestamp;
• owner and group;
• ACL;
• Finder tags;
• arbitrary extended attributes;
• cloud sharing permissions;
• cloud revision history.

Hash the file to verify content. Audit metadata to verify metadata.

Build a metadata manifest before a serious migration

For a small personal folder, manually checking a few dates may be enough. For a real archive, create a manifest.

At minimum, record:

• relative path;
• byte size;
• content checksum;
• filesystem modified time;
• filesystem creation/birth time where available;
• file type;
• any metadata field that your workflow actually depends on.

For metadata-sensitive workloads, add platform-specific information such as:

• Unix mode, UID and GID;
• ACL entries;
• relevant extended attributes;
• symlink target;
• Finder tags or other macOS-specific metadata;
• cloud permission/owner exports if collaboration state must be recreated.

Do not collect every possible metadata field merely because it exists. Define the preservation contract first.

A useful contract might be:

All file bytes must match, relative paths must match, embedded photo metadata must match, filesystem modified times must remain within one-second resolution, and cloud sharing permissions will be rebuilt separately.

That is testable. "Preserve all metadata" is usually not.

The safest migration workflow

Use this sequence when metadata matters enough that a silent change would be expensive.

1. Freeze or snapshot the source

Do not compare metadata while applications are still modifying the files. For live databases or catalogs, create an application-consistent export or backup rather than treating a changing working file as an archive.

2. Build the content + metadata manifest

Record the fields you have decided matter.

3. Keep the original storage intact

A cloud upload is not permission to erase the only known-good source.

4. Upload using the transfer path you actually intend to use

Desktop app, browser, API and migration service can have different metadata behavior. Test the actual production path.

5. Verify cloud-side state

Check file counts, sizes, timestamps exposed by the provider, and any permission mapping you expected.

6. Re-download a representative sample to a fresh location

Do not compare against a cached or already-synced local file. You want a real round-trip test.

7. Compare contents and metadata separately

A checksum match should be one column in the report, not the entire report.

8. Restore into the downstream application

If Lightroom, a DAM, a build system or another application depends on the metadata, open the restored sample there. The application is the final consumer of the metadata contract.

9. Only delete the old source when the preservation contract passes

If one required metadata field is missing, fix the migration method before scaling it.

When an archive container is safer than loose files

For some metadata-sensitive cold archives, putting a directory tree inside a metadata-aware archive format before cloud upload can reduce cross-filesystem translation problems. A suitable TAR-based workflow, for example, can preserve selected timestamps, mode bits, symlinks and — with the right implementation and flags — extended attributes.

But this is not a universal "zip it" recommendation.

Trade-offs include:

• losing convenient per-file cloud browsing;
• losing granular per-file version history;
• needing enough local space to restore the archive;
• depending on the exact archive tool and options used;
• still needing an independent checksum for the archive itself.

For a 500,000-file immutable research snapshot, an archive container may be useful. For an active working tree, it can be the wrong abstraction.

If the real decision is whether cold data belongs in cloud storage or on separate hardware, compare Cloud Storage vs External Hard Drive before redesigning the whole archive.

The Big 5 metadata decision in one table

The pattern is more important than the vendor names: cloud providers model files as cloud objects, not as universal disk-image containers for every filesystem semantic.

Stay with your current provider if the metadata contract already passes

Do not switch clouds just because another API exposes more metadata fields.

Stay with Dropbox if its desktop transfer preserves the dates you need and your workflow already verifies them. Stay with OneDrive if Microsoft 365 collaboration is the important layer and your migration tooling handles fileSystemInfo correctly. Stay with Google if its sharing and metadata model is already the system of record. Stay with iCloud if the entire workflow lives inside Apple's ecosystem and your restore tests pass.

A provider change is justified only when the current workflow cannot meet the preservation contract at an acceptable operational cost.

For pCloud, the relevant advantage here is narrower: its API exposes explicit timestamp controls that can be useful in a storage-first migration pipeline. That can matter to an archive workflow, but only after you prove the whole restore path.

The rule to remember

A cloud migration is complete only when the things you care about survive the round trip.

For many users that means only:

• correct files;
• correct contents;
• usable folder structure.

For a metadata-sensitive archive it may also mean:

• correct modification dates;
• preserved embedded metadata;
• selected xattrs;
• explicit permission reconstruction;
• a documented mapping between cloud timestamps and local timestamps.

The mistake is not losing an obscure metadata field you never needed. The mistake is assuming you preserved a field you never tested.

That is why the final migration question is not:

Did the upload finish?

It is:

Can I restore a fresh copy and prove that the bytes, dates and metadata my workflow depends on are still there?

Sources and verification

Product behavior can change. The following primary sources were checked on 21 August 2026:

1. Dropbox Help — Modified dates for files and folders: https://help.dropbox.com/organize/modified-date
2. Dropbox Help — Extended attributes: https://help.dropbox.com/sync/extended-attributes
3. Google Drive API — File resource metadata: https://developers.google.com/workspace/drive/api/reference/rest/v3/files
4. Google Drive API — Files and folders overview: https://developers.google.com/workspace/drive/api/guides/about-files
5. Microsoft Graph — fileSystemInfo resource: https://learn.microsoft.com/en-us/graph/api/resources/filesysteminfo?view=graph-rest-1.0
6. Microsoft Support — Copy, transfer or import files to personal OneDrive: https://support.microsoft.com/en-us/onedrive/copy-transfer-or-import-files-to-your-personal-onedrive
7. Apple Developer — File Provider extendedAttributes: https://developer.apple.com/documentation/fileprovider/nsfileprovideritemprotocol/extendedattributes
8. pCloud Developers — stat: https://docs.pcloud.com/methods/file/stat.html
9. pCloud Developers — uploadfile: https://docs.pcloud.com/methods/file/uploadfile.html
10. pCloud Developers — copyfile: https://docs.pcloud.com/methods/file/copyfile.html

<!-- DRAFT PRODUCTION NOTES Article fingerprint:

• Intent: troubleshoot changed dates/metadata after cloud upload, download or migration.
• Unique angle: four-layer metadata model; explicit separation of content integrity, embedded metadata, filesystem metadata and cloud-service metadata.
• Non-overlap: not a checksum article, not a generic migration comparison, not a filename/path restriction article.
• Decision gap: user must define a preservation contract before deciding a provider or deleting source storage.

Verified live internal links used in body:

• /articles/backup-vs-cloud-storage/
• /articles/cloud-storage-vs-external-hard-drive/

No batch-draft links are included before publish-time 200 verification.

Reverse-link suggestions for 50/50 publish QA only; add only after this URL returns direct HTTP 200:

1. /articles/backup-vs-cloud-storage/ — link from sections discussing what ordinary sync does not preserve.
2. /articles/cloud-storage-vs-external-hard-drive/ — link from archive-migration and filesystem-preservation trade-offs.
3. /articles/pcloud-drive-cache-explained/ — link from pCloud architecture section when discussing virtual-drive storage versus archival fidelity.
4. /articles/google-drive-alternatives/ — link from migration considerations when metadata requirements, not office workflow, drive provider choice.
5. Draft #35 checksum article — add reciprocal link only after both final URLs return direct 200 and are in the same publish batch.

Image metadata:

1. cloud-file-metadata-four-layers-hero.svg

Purpose: distinguish content, embedded metadata, filesystem metadata, cloud metadata. Placement: after introduction. ALT: Four-layer cloud file metadata model separating file bytes, embedded metadata, filesystem timestamps and permissions, and cloud-service metadata. Source: Original CloudScope technical diagram based on documented provider metadata models. Dimensions: 1200x760.

1. cloud-file-timestamps-service-vs-filesystem.svg

Purpose: show why local-created Monday / uploaded Tuesday can create different valid timestamps. Placement: OneDrive section. ALT: Diagram distinguishing local filesystem creation and modified times from cloud service creation and modified times. Source: Original CloudScope diagram derived from Microsoft Graph fileSystemInfo documentation. Dimensions: 1200x760.

1. cloud-file-metadata-migration-workflow.svg

Purpose: safe verification flow from source manifest through upload, re-download and metadata comparison. Placement: migration workflow section. ALT: Metadata-aware cloud migration workflow showing manifest creation, upload, fresh restore, checksum comparison and metadata audit. Source: Original CloudScope workflow diagram. Dimensions: 1200x760.

CTA metadata:

• One commercial CTA only.
• Plan: General Plans & Pricing — https://partner.pcloud.com/r/156919
• Reason: problem/education stage; pCloud API timestamp controls are relevant but not sufficient to justify Lifetime/Family/Business/Crypto routing.
• Disclosure: rel="sponsored noopener" and explicit affiliate label.

Publish/index QA:

• Final canonical must be exactly https://cloudscope.org/articles/cloud-storage-changed-file-dates-metadata/
• Canonical URL must return direct 200, not 301/302.
• Register slug once only.
• Do not expose draft or alternative slug.
• Do not add to sitemap before article route and all 3 image assets are wired.
• Confirm no equivalent live intent exists before wiring.
• Verify all internal links return direct 200 at publish time.
• Keep self-canonical and index,follow,max-image-preview:large only after successful route QA.

-->