WebDAV upload does not preserve file modification times

[phernandez]

Problem

When uploading files via , the file modification times are not preserved. Files get new modification times set to the upload time instead of keeping their original timestamps. This causes issues with:

1. Sync accuracy: The sync system relies on filesystem timestamps (per fix: Use filesystem timestamps for entity sync instead of database operation time (#138) #369) to detect changes
2. Historical context: Users lose the temporal context of when notes were actually created/modified
3. False sync triggers: Files with changed timestamps may trigger unnecessary syncs

Current Behavior

Client side (src/basic_memory/cli/commands/cloud/upload.py:86-91):

• Reads file content and sends via HTTP PUT
• Does not include original modification time in request

Server side (apps/api/src/basic_memory_cloud_api/webdav.py:203-248):

• Writes file content without preserving modification times
• Files get current timestamp

Expected Behavior

Files uploaded via WebDAV should retain their original modification times.

Solution

Implement modification time preservation in both client and server:

1. Client: Read file's st_mtime and send as HTTP header (e.g., X-OC-Mtime or Win32LastModifiedTime)
2. Server: Read modification time header and use os.utime() to set it after writing file

Affected Components

• basic-memory: CLI upload command (client side)
• basic-memory-cloud: WebDAV server (server side)

Related Issues

• fix: Use filesystem timestamps for entity sync instead of database operation time (#138) #369 - Uses filesystem timestamps for entity sync
• [DOCS] spelling error "Chose a folder" instead of "Choose a folder" #138 - Originally introduced filesystem timestamp usage

[claude]

Claude finished @phernandez's task —— View job

---

Issue Triage Analysis

I've analyzed this issue and performed triage. Here's my assessment:

Classification

Type: Bug + Enhancement

• This is a bug because WebDAV uploads should preserve file modification times but currently don't
• It's also an enhancement because the feature needs to be added to both client and server

Priority: High

• Impact: Affects sync accuracy, a core feature of Basic Memory
• Scope: Related to PR fix: Use filesystem timestamps for entity sync instead of database operation time (#138) #369 which fixed local filesystem timestamps - this is the cloud counterpart
• User Impact: Causes false sync triggers and loss of temporal context

Component: Cloud (WebDAV functionality)

• Client side: src/basic_memory/cli/commands/cloud/upload.py
• Server side: apps/api/src/basic_memory_cloud_api/webdav.py (separate repo)

Complexity: Medium

• Straightforward implementation (HTTP headers + os.utime())
• Requires changes in two repositories (basic-memory and basic-memory-cloud)
• Well-defined solution already proposed

Current Implementation Analysis

From reviewing src/basic_memory/cli/commands/cloud/upload.py:

• Lines 86-91: Client reads file content but does not capture or send modification time
• Uses aiofiles.open() to read content, then sends via call_put()
• No headers are added to preserve timestamps

Proposed Solution

The issue correctly identifies the fix:

1. Client (basic-memory):

   • Capture file_path.stat().st_mtime before upload (line 86)
   • Add HTTP header (e.g., X-OC-Mtime or Win32LastModifiedTime)
   • Pass header to call_put() function

2. Server (basic-memory-cloud):

   • Read modification time from HTTP header
   • After writing file content, use os.utime(path, (atime, mtime)) to set timestamp

Related Context

• PR fix: Use filesystem timestamps for entity sync instead of database operation time (#138) #369 (merged): Fixed local filesystem timestamp handling - this is the cloud equivalent
• Issue correctly references that sync relies on filesystem timestamps
• No duplicate issues found

Labels Applied

• bug - Feature not working as expected
• cloud - Affects cloud functionality
• enhancement - Requires new functionality to be added

Recommendation

This issue is ready for implementation. The problem is well-defined, the solution is clear, and it's a high-priority fix that complements the recent work done in PR #369 for local sync.

Next Steps:

1. Implement client-side changes in basic-memory repository
2. Implement server-side changes in basic-memory-cloud repository
3. Add tests to verify timestamps are preserved end-to-end
4. Consider which header standard to use (X-OC-Mtime is used by ownCloud/Nextcloud, Win32LastModifiedTime is used by some WebDAV servers)

---