Last Modified date of folders in sshfs mounted SFTP drive is 01-01-1970

[ghost]

I am using sshfs to mount a SFTP folder on my CentOS. I have noticed that the last modified date of all folders in the mounted drive is '01-01-1970'. I don't see this issue in FTP clients. That is, I see correct 'last modified' date on folders when I connect to the same SFTP server via Filezilla, Cyberduck and sftp utility on Mac. I can use Webdrive to mount SFTP on Mac Finder and see the correct date and time on folders. The issue is limited to sshfs mounted sftp drive.

[Nikratio]

Thanks for the report! Do you think you could work on this (or do you know someone who could)?

SSHFS is a fully volunteer driven project. This means that new features and bugfixes are implemented only when someone has a personal interest in them and therefore also does the necessary work. So if someone (that probably means you) is interested in working on this, then I'd be happy to give guidance and review patches. If not, I will close this issue in a few days (since the purpose of the issue tracker is to coordinate ongoing and planned work, rather than enumerate all the work that could possibly be done).

[Cheste]

@Nikratio I've experienced the same issue with sshfs. During the debuging found out that if server provide only modification timestamp without access timestamp sshfs will expose Unix start time instead.
I think this is the place in the code where you return the exception if one of the parameter is not set.

FYI: using linux console sftp command or FileZilla no issues at all(It seems they know how to handle absence of the access time attribute).
I'm not a C guy, I'd like to help you guys to support your tool but it would take much more time for me then to add access time on my side to solve this issue.
Cheers

[Nikratio]

I'm closing this issue for now. Please note that this isn't meant to imply that you haven't found a valid bug or potential improvement - you most likely have and I'm grateful that you took the time to report it.

Unfortunately, this project does not currently have any active, regular contributors or developers. The current maintainer continues to apply pull requests and tries to make regular releases, but unfortunately has no capacity to do any development beyond addressing high-impact issues. Any other reports are therefore likely to languish unless they come together with a high-quality pull request.

This report unfortunately does not fall into either category, so with the current state of affairs it's unlikely that anyone is going to be able to do anything but this anytime soon, and I prefer to use the issue tracker as a tool to manage ongoing work (as opposed to a database of known/potential issues).