[BR-1308] Fix: Properly add original file modification and creation time

[AlexisMora]

What is Changed / Added

Added original file creation and modification time

Summary by CodeRabbit

• New Features

  • File synchronization now preserves and sends file creation dates alongside modification dates.
  • Uploaded, created, and replaced files retain accurate timestamp metadata.

• Bug Fixes

  • Improved timestamp handling for empty files and successfully uploaded files.
  • File replacement requests now include creation-time information.

[coderabbitai]

📝 Walkthrough

Walkthrough

Changes

File upload results now include creation timestamps derived from filesystem birth times. Create and replace sync actions forward modification and creation timestamps as ISO strings, and the replace API request includes the new creation-time field.

File timestamp collection

Layer / File(s)	Summary
Collect upload timestamps src/backend/features/sync/actions/services/upload-file.ts, src/backend/features/sync/actions/services/upload-file.test.ts	Upload metadata includes mtime and creationTime for empty and successful files, with tests validating the returned object shape.
Forward timestamps through sync actions src/backend/features/sync/actions/services/create-file.ts, src/backend/features/sync/actions/services/create-file.test.ts, src/backend/features/sync/actions/services/replace-file.ts, src/backend/features/sync/actions/services/replace-file.test.ts	Create and replace actions pass modification and creation timestamps as ISO strings, with expanded persistence assertions.
Send creation time in replace requests src/infra/drive-server-wip/services/files.service.ts	The replace-file context requires creationTime, and the PUT request body includes it.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: adding original creation and modification timestamps.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/br-1308-incorrect-timestamp-on-backup

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

src/backend/features/sync/actions/services/upload-file.ts (1)

23-26: 🩺 Stability & Availability | 🔵 Trivial

Platform availability of birthtime.

On Linux filesystems that don't support birth time (e.g., older ext4, tmpfs, overlayfs), fs.stat().birthtime returns the epoch (1970-01-01T00:00:00.000Z). This would propagate an incorrect creation timestamp to the backend. Consider whether a fallback (e.g., using mtime when birthtime is epoch) is needed for robustness.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/backend/features/sync/actions/services/upload-file.ts` around lines 23 -
26, Handle unsupported birth times in the metadata returned by the upload-file
logic: when the `birthtime` from `stat(path)` is the epoch, use `mtime` as the
creation timestamp instead. Update the return path for empty files and any
corresponding timestamp handling so `creationTime` never propagates an invalid
epoch value.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/backend/features/sync/actions/services/upload-file.ts`:
- Around line 23-26: Handle unsupported birth times in the metadata returned by
the upload-file logic: when the `birthtime` from `stat(path)` is the epoch, use
`mtime` as the creation timestamp instead. Update the return path for empty
files and any corresponding timestamp handling so `creationTime` never
propagates an invalid epoch value.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 144f00d7-e2f5-490b-bb8e-da9ef9652a5e

📥 Commits

Reviewing files that changed from the base of the PR and between ecda67e and 421b277.

📒 Files selected for processing (7)

• src/backend/features/sync/actions/services/create-file.test.ts
• src/backend/features/sync/actions/services/create-file.ts
• src/backend/features/sync/actions/services/replace-file.test.ts
• src/backend/features/sync/actions/services/replace-file.ts
• src/backend/features/sync/actions/services/upload-file.test.ts
• src/backend/features/sync/actions/services/upload-file.ts
• src/infra/drive-server-wip/services/files.service.ts

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud