Mounted FTP shows wrong change date ("Years ago" - 01.01.1970)

[stefan-niedermann]

Server configuration

Operating system: Debian Squeeze

Web server: Apache/2.2.16

Database: MySQL

PHP version: 5.3.3-7

ownCloud version: 6

Updated from an older ownCloud or fresh install: fresh install

List of activated app: standard

The content of config/config.php: (Without the database password and passwordsalt)

Client configuration

Browser: any

Operating system: any

Logs

no errors shown in server-log, oc-log or browser-log

[karlitschek]

@PVince81

[PVince81]

@stefan-niedermann Please fill out the issue template https://raw.github.com/owncloud/core/master/issue_template.md

Without version numbers it will be hard to reproduce.
Also, please specify the FTP server type and version.
Thanks.

[stefan-niedermann]

I'm not sure i can get infos about the ftp-sever, i'm only customer of a shared hoster.
is the filezilla-log maybe interessting?

[PVince81]

I just had another look at your screenshot and remembered that there is an issue because we can't get "modified date" for FTP folders. At least when using PHP's stat() the date will be empty or zero.
Either it's a bug in PHP or the FTP server don't store, maintain or return dates for folders.
Needs more research.

Does your filezilla client show the correct folder date in its UI ?

Needs more research.

[stefan-niedermann]

Yes, Filezilla client shows correctly:

[jancborchardt]

If the date is empty or zero, it’s most probably an error. In that case the date column should show a »?« with a tooltip »Date can’t be determined«. Much like for the size column.

[stefan-niedermann]

Also, please specify the FTP server type and version.

type: vsftpd
version: latest available Raspbian repo

(Was not the original server which caused this issue, but it happens definitly too with this server (see #10916)

[davidows]

Actually, there may be a simple workaround to "trick" Filezilla into displaying the date you expect to see. Simply create a file in the root folder with a name such as "! This file MUST REMAIN HERE". Be sure to begin the filename with the exclamation point, but do not include the quotation marks.

Actually, the only requirement is that the first object (file or folder) alphabetically in the login folder MUST be a FILE. In other words, if the first FOLDER alphabetically is named "Archive", any FILE name alphabetically ahead of "Archive" would work, even "Archivd". If the first FOLDER is named "Archives", then a FILE named "Archive" would work.

Although Folders are always displayed above Files when sorted alphabetically, that doesn't matter for this purpose. Using the exclamation point ensures that it's very unlikely a folder would ever have a name alphabetically ahead of the filename.

I don't know why this workaround has never been posted before in the Filezilla Forum for users searching for a solution to the problem. This comes from a bug report comment on Ticket #3698 by Sean Devoy (of Filezilla Project) over 3 years ago:

Quote:
Changed 3 years ago by SeanDevoy

cc sdevoy@… added

I have additional information that explains WHEN and WHY this happens:
My Server is running FreeFTPd and I use it in sftp mode on Windows 2008 R2.

when connecting with FileZilla from my Windows 7 client, sometimes the dates are fine, others they are screwey. I have found that if the FIRST file or directory (alphabetically) is a Directory the mtime function fails when getting the timezone offset. If the first object is a FILE the mtime function succeeds and calculates the correct timezone offset.

Now, having observed that, I do not know if the "error/bug" is in FileZilla client or FreeFTPd server. Here is some sample output:

Status: Calculating timezone offset of server...
Command: mtime "Admin"
Response: 4294967295
Status: Timezone offsets: Server: 1312383480 seconds. Local: -18000 seconds. Difference: -1312401480 seconds.

Status: Calculating timezone offset of server...
Command: mtime "AboutUs.html"
Response: 1309747324
Status: Timezone offsets: Server: -18000 seconds. Local: -18000 seconds. Difference: 0 seconds.

I suppose creating an aaaa.txt file in the login folder would be a workaround.

Hope that helps.