Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#7760 closed Bug report (worksforme)

Jan 01 1601 Directory

Reported by: Patrick Owned by:
Priority: normal Component: FileZilla Client
Keywords: Directory, Dir, Folder Cc: eric.howard@…
Component version: Operating system type: Windows
Operating system version: Windows 7 Enterprise

Description

The SFTP server is a IPSwitch WS_FTP Enterprise Server, version 7.5.1.2. There are two virtual directories in a home folder but a folder named "Jan 01 1601" is added to every site that I connect to. The folder does not exist at the file system and is not a virtual directory.

After some research the date "Jan 01 1601" has some significance in Windows. "January 1 of this year (1601-01-01) is used as the base of file dates[1] and of Active Directory Logon dates[2] by Microsoft Windows" -http://en.wikipedia.org/wiki/1601

I've used tested the same site with WinSCP and native sftp in RedHat Enterprise Linux 5. The other SFTP clients does not display this folder.

See attached files for more details.

Attachments (6)

Log.txt (673 bytes) - added by Patrick 8 years ago.
Screenshot.png (91.4 KB) - added by Patrick 8 years ago.
Screenshot2.png (89.9 KB) - added by Patrick 8 years ago.
Screenshot3.png (7.9 KB) - added by Patrick 8 years ago.
Screenshot4.png (107.9 KB) - added by Patrick 8 years ago.
RawDirectory.txt (17.4 KB) - added by Eric Howard 6 years ago.

Download all attachments as: .zip

Change History (13)

Changed 8 years ago by Patrick

Attachment: Log.txt added

Changed 8 years ago by Patrick

Attachment: Screenshot.png added

Changed 8 years ago by Patrick

Attachment: Screenshot2.png added

Changed 8 years ago by Patrick

Attachment: Screenshot3.png added

Changed 8 years ago by Patrick

Attachment: Screenshot4.png added

comment:1 Changed 8 years ago by Patrick

CoreFTP does not have this issue either, see Screenshot4.png.

comment:2 Changed 7 years ago by Alexander Schuch

Status: newmoreinfo

This looks like an error in directory listing parsing.

Can you please enable "raw directory listing" and attach the raw listing here? Please first try to reproduce the problem with current version of FileZilla.

comment:3 Changed 6 years ago by Alexander Schuch

Resolution: outdated
Status: moreinfoclosed

No reply for more than 28 days.

comment:4 Changed 6 years ago by Eric Howard

Cc: eric.howard@… added
Resolution: outdated
Status: closedreopened

I too am having this issue with this version

FileZilla Client


Version: 3.7.3

Build information:

Compiled for: i586-pc-mingw32msvc
Compiled on: x86_64-unknown-linux-gnu
Build date: 2013-08-07
Compiled with: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.12
GnuTLS: 3.1.11
SQLite: 3.7.16.2

Operating system:

Name: Windows NT 6.1 (build 7601, Service Pack 1)
Version: 6.1
Platform: 64 bit system

Please let me know what other information you may need.

comment:5 Changed 6 years ago by Alexander Schuch

Status: reopenedmoreinfo_reopened

Can you please enable "raw directory listing" and attach the raw listing here, see information about logs?

Changed 6 years ago by Eric Howard

Attachment: RawDirectory.txt added

comment:6 Changed 6 years ago by Patrick

Status: moreinfo_reopenedreopened

During a packet capture using Wireshark the dates are reported incorrectly from WS_FTP. This is not an issue wit FileZilla but is a but within WS_FTP not being able to read the date/time stamp on the folder. To allow this, you can set special file permissions to the user that WS_FTP impersonates the user as to read attributes only on the folder which it is trying to get the date/time stamp for. This will resolve the issue. WS_FTP does not have permissions to read the directory attribute and defaults to Jan 01 1601 upon failure.

comment:9 Changed 6 years ago by Alexander Schuch

Resolution: worksforme
Status: reopenedclosed

Okay, so this is not a bug with FileZilla but a bug/issue/feature in WS_FTP along with a permission issue there. Closing this as "not a bug".

Note: See TracTickets for help on using tickets.