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

Jump to bottom

File mtime of retrieved files reflects cached mtime after edits #4599

Closed
cyberduck opened this issue Jun 28, 2010 · 3 comments
Closed

File mtime of retrieved files reflects cached mtime after edits #4599

cyberduck opened this issue Jun 28, 2010 · 3 comments
Assignees
@dkocher
Labels
bug core fixed
Milestone
3.6

Comments

@cyberduck
Copy link
Collaborator

4acee99 created the issue

To reproduce -

  • Open FTP connection to server.
  • Identify a file you can edit which has a date in the past.
  • Use Cyberduck "Edit" (CMD+K) to edit the file.
  • Complete edit and save file.
  • Drag the file from the Cyberduck window to the local disk.

mtime of local file will be the mtime it was before the edit. To get the updated mtime, Cyberduck needs to refresh its file listing.

Suggest as a fix that after uploads, Cyberduck should do a partial LS to update its cache of file modification times.

Cyberduck Version 3.5.1 (6117) on OSX10.6.4
@cyberduck
Copy link
Collaborator Author

4acee99 commented

If it's not already obvious from the above -

Difference betw expected behaviour and actual is that I expect the MTIME to reflect the edit I've just made via Cyberduck, and for the retrieved files to sit at the top of the Finder list when sorted by date. Actual behaviour is that the files will have historic dates instead, although the file contents are (of course) correct.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

We currently do not refresh the directory listing after edits for performance reasons but should possibly change that policy.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 40f1071.

@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.
Assignees

@dkocher dkocher

Labels
bug core fixed
Projects
None yet
Milestone
3.6
Development

No branches or pull requests
2 participants
@dkocher @cyberduck