Cyberduck Mountain Duck CLI

#10818 closed defect (worksforme)

Support to set file modification date

Reported by: highfalutin Owned by: dkocher
Priority: normal Milestone:
Component: b2 Version: 7.1
Severity: normal Keywords: mountain duck
Cc: Architecture: Intel
Platform: macOS 10.14


When a file is copied into a Mountain Duck mounted volume, its modification date is set to the current time, regardless of the original file's modification time.

Steps to reproduce

  1. Mount a B2 bucket as a Mountain Duck volume in the Mac Finder.
  2. Choose a file created sometime in the past, outside the Mountain Duck volume.
  3. Copy the file into the Mountain Duck volume by dragging it between windows.
  4. Wait for the copied file to appear in the Mountain Duck volume.
  5. "Get info" on the copied file, and on the original file.

Expected behavior

The modification timestamps for the two files should be the same.

Actual behavior

The modification timestamp for the copied file is the time at which it was copied.

In the Finder, when I copy the file, the copied file very briefly shows the correct modification date in the file listing, but after a second it changes.

See attached video which shows the behavior.

Attachments (1)

copy-file-to-mountain-duck-b2.mp4 (112.3 KB) - added by highfalutin on Sep 26, 2019 at 6:21:52 PM.
Screenshot video demonstrating the issue

Download all attachments as: .zip

Change History (9)

Changed on Sep 26, 2019 at 6:21:52 PM by highfalutin

Screenshot video demonstrating the issue

comment:1 Changed on Sep 30, 2019 at 8:09:43 AM by dburnier

  • Platform changed from macOS 10.14 to Windows 10

The same under Windows 10 or Windows 7.1.

I will just add that timestamps are correctly managed for download (S3->local). The problem is just for upload (local->S3).

I can validate that the options "Preserve modification date" on Preferences / Transfers / Timestamps is working only for Downloads but not at all for Uploads.

And with MountainDuck it's the same except that some time this parameter for Downloads seems blocked at true or false and is not managed by the CyberDuck parameters; and I've tested to be sure by modifying under Cyberduck during MountainDuck left, then leaving CyberDuck and testing by launching again MountainDuck. That's not really clear how the parameters used under MountainDuck are linked with the CyberDuck ones.

Thanks for your support and best regards.

comment:2 Changed on Oct 2, 2019 at 1:41:37 PM by dkocher

  • Component changed from core to b2
  • Summary changed from Mountain Duck fails to set file modification times (MacOS, B2) to Fails to set file modification times

comment:3 Changed on Oct 2, 2019 at 1:43:21 PM by dkocher

Can you clarify if you refer to Backblaze B2 or Amazon S3.

comment:4 Changed on Oct 2, 2019 at 2:07:50 PM by dburnier

It's on Amazon S3 compatible, more exactly Scality.

comment:5 Changed on Oct 2, 2019 at 2:15:07 PM by dkocher

  • Component changed from b2 to s3
  • Owner set to dkocher

comment:6 Changed on Oct 2, 2019 at 2:16:11 PM by dkocher

  • Summary changed from Fails to set file modification times to Support to set file modification date
  • Type changed from defect to enhancement

The S3 API does not have native support to store the modification date. We would have to set it in a custom property in the user metadata.

comment:7 Changed on Oct 2, 2019 at 2:41:48 PM by highfalutin

  • Component changed from s3 to b2
  • Platform changed from Windows 10 to macOS 10.14
  • Type changed from enhancement to defect

I'm the original reporter of this ticket and I'm talking about B2.

comment:8 Changed on Oct 23, 2019 at 6:49:17 PM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

We do set the modification date for files in B2 in the src_last_modified_millis metadata property. Please write to support@… if this is still an issue.

Note: See TracTickets for help on using tickets.
swiss made software