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
Modification Time Lost #6669
Comments
Try to check Preferences → Transfers → Uploads → Preserve modification date. |
I should have made that clear.... preserve modification date for both upload and download are checked. |
Can you please post the transcript from the log drawer (⌘-L) of the Transfers window. |
The problem is that this doesn't always happen. It only happens on occasion. I'll try a few things and then, if it doesn't occur in the next few minutes, I'll have to keep my eye out for it during my normal work. |
Well it took 2 months but I finally had this happen again. Fortunately I've been keeping the log drawer open by default so i could find it. Here's the extended segment of the log showing the problem:
So I did ⌘-K to edit localdata.ini file and let it save. The modification time is clearly Jan 1, 1970. I'm not sure who is responsible for deciding the modification time in this case (cyberduck or textmate), but it would seem that some sort of alert/confirmation could be presented verifying the modification date when it 0ms (perhaps with the option to set the timestamp) would be advisable since its rarely the case that files these days are modified in 1970. |
It happens with some frequency that if I edit-in-place some text file with TextMate that the modified time on the remote machine is something in 1969 which I suspect is just being set to 0. This isn't normally a big deal except that one machine this happens on has a script that seems to be throwing up when the modified time is in this state.
The text was updated successfully, but these errors were encountered: