Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support to set file modification date #10818

Closed
cyberduck opened this issue Sep 26, 2019 · 6 comments
Closed

Support to set file modification date #10818

cyberduck opened this issue Sep 26, 2019 · 6 comments
Assignees
Labels
b2 Backblaze B2 Protocol Implementation bug worksforme

Comments

@cyberduck
Copy link
Collaborator

2e6f660 created the issue

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

@cyberduck
Copy link
Collaborator Author

9925094 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

9925094 commented

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

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

2e6f660 commented

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

@cyberduck
Copy link
Collaborator Author

@dkocher commented

We do set the modification date for files in B2 in the src_last_modified_millis metadata property. Please write to [mailto:support@mountainduck.io] if this is still an issue.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
b2 Backblaze B2 Protocol Implementation bug worksforme
Projects
None yet
Development

No branches or pull requests

2 participants