Core FTP

Hi,
I have problem connecting from the last version of Filezilla to the SFTP, and the date appears wrong, and it put the 1/1/1970. I checked Filezilla forum and they says that it's a problem with the returning date from CoreFTP.
Someone else have the same problem? Some way to solve it?

Thanks and best regards.

Yes, the computer have the correct date/time and the files too.
I supposed they change the way to control the date/time because with previous versions of Filezilla it worked correctly.

I also am having major time problems. At 1st I thought it was just Filezilla, but now I'm not so sure. I had switched to WinSCP for most use due to filedate & time issues, but then one of my users noticed that when she uploaded a file the time was off by a few hours. I was able to duplicate the error. I had not noticed it at 1st due to the correct date being in place. After much trial & error, I found that having the "No GMT" setting checked seemed to cause the problem. After unchecking it and restarting the Coreftp service, the problem went away for both WinSCP & Filezilla. Unfortunately, a few weeks later I have the same problems again. About a week ago I upgraded to build 283. So I figured it must be due to that. So I downgraded to build 279 which I was using before. Unfortunately now it doesn't matter what version I run, the filedates in Filezilla all show around 1969. However, it appears that WinSCP times & dates are correct. All of my tests are being run in the central time zone, with all servers/workstations in the same zone & correctly configured. Anyone have any ideas?
Thanks.

Oh, I forgot to mention above that I am only using sftp.
Thanks.

I tried with the "No GMT" check, and it didn't work for me either. I'm not sure if the problem is the coreftp or the filezilla and I'm using also SFTP.

I've found a clue to what may be happening with the messed up times:

When I connect to the server using sftp using say Filezilla, upon connection it runs the command mtime "xxxx" where xxxx is the name of a file or folder. If xxxx is the name of a file, the correct dates get returned. If xxxx is a name of a folder, the 1969 or so crazy dates get returned. I don't know how a file vs folder gets chosen, but in my experiments the results are consistent. I ran my tests by noting the difference in 2 different CoreFTP servers, and then removing files from the root sftp directory on one. When there were no more files, a folder was chosen and from that point the times were skewed. I put the files back, and alas upon connection the times were right again. Unfortunately, on the server I really need this fixed on it chooses a folder instead of the files no matter what, and thus returns the skewed dates.

Hi, I have the same problem, with filezilla.
Is this a problem in the server or incorrect user settings somewhere?

I have played around with no GMT, without any progress.

This is what I see in filezilla:
Status: Calculating timezone offset of server...
Command: mtime "Upload"
Response: 4294967295
Status: Timezone offsets: Server: 1255256340 seconds. Local: 7200 seconds. Difference: -1255249140 seconds.

Any inputs from coretFTP team?

Thanks!

The workaround mentioned above works partially.

If you have virtual folders in your root and put a single file in the root folder.
The date and time are not correct for your virtual folders (are always current time and date, changes every time your refresh).
Inside the virtual folders the time and date are correct.

example:

root
|- dummy.txt [file]
|- Virtual 1 [folder]
|- Virtual 2 [folder]
|- Virtual 3 [folder]

Something for the core team, Virtual Folders??!

I can confirm that this is still an issue. The work aorund of using a file in the root of the directory does do the trick.

My configuration is CoreFTP Server running on Windows Server and connecting with FileZila FTP client. In my case, the MTIME response always returns 0 (zero).

By adding a file to the root directory (I just went with -800 and no extension), the correct response for the MTIME command is returned.

Looks like this is an issue only when MTIME targets a folder.