Open nnn19 opened 1 year ago
Can you test older versions and see what version introduced the bug?
I identified the cache as a possible source of bugs a while ago, I didn't change how it works. But it did give me headaches several times
Perhaps the cache should be disabled globally, it's not that important nowadays, perhaps it's something that should be implemented by the server instead, to prevent abuse
I'm not able to reproduce the bug, you're using ubuntu 22 right, so it's probably a glib issue that happens after certain version
What server are you connecting to? proftpd? netbsd? pureftpd? vsftpd?
Hard to tell what's going, but I had the idea to remove the cache because it was interfering with my test procedures. It also perhaps played a role in a couple of random crashes when I was connecting to many ftp servers before releasing 2.9.0 probably
I often need more info that people are willing/able to provide (i.e. @iandoug), so I guess I'll probably remove the cache stuff, it will make gftp more reliable
That would be the best solution for you and me, I probably understand the codebase better than anyone else. So unless someone steps up and provides all the fixes I cannot, making gftp less fancy and buggy by removing some unneeded code is the way to go
See gnome-videos for the possible roadmap
I've been connecting to random ftp servers around the world, and I'm unable to replicate the bug, gftp handles all sorts of servers gracefully
Except one server that sends text in Norwegian, systype Windows_NT, detected DOS dir listing.... empty filenames, remote file date 1969/12/31. I also see g_utf8_validate errors The server supports the UTF8 and LANG extensions, could this be fixable?
I had Ubuntu Mate 18 and gftp connected to same servers quite properly.
The server has CentOS 7 and ProFTPD Version 1.3.5e
in both the cases of Ubuntu 18 and 22.04.
Any further materials - log / trace, etc - I can give. Please suggest.
Not really sure the server is the problem, I saw a few proFtpd servers during my tests and the dates were always correct... Using the latest git revision
Right now I'm using Slackware 14.2. Removing or disabling the cache is probably the best solution
Server is fine - as the same with the same configurations had served FTP clients perfectly for the past few years to Ubuntu older version / gFTP older versions.
Immediately after getting the gFTP 2.9.1b, the issue popped up. And I am still clearing the cache folder or changing the folders through the folder name bar (above the directory view to arrive at the correct file date / time.
Also, changing the folders through the folder name does not correct the issue all the times. But clearing the cache folder would for sure.
Testing the 2.9.1 release tarball with ProFTPD 1.3.1rc2 (and 2 other versions)... unable to reproduce the bug. I think I also connected to a ipv6 address, hmmm
Using FTPS (disabled SSL verfication)... 1 Filezilla Server, 1 pure-FTPd, ... OK vsFTPd doesn't support anonymous users in TLS mode I think Most public servers don't enable TLS
Are you using FTPS?, FTPSi? Ipv6?
So this is something I cannot fix since I cannot reproduce it, but everyone already knows what can be done to fix this issue.. And it shall be done
The server has SSL. But ProFTPD is contacted through just FTP. Yes. IPv6
After many more tests.. I guess I need to use ubuntu, but that's not gonna happen anytime soon
Gtk and Glib are probably patched versions that may behave differently under certain conditions
Reminds me of pup-volume-monitor (glib app), years ago it worked well with Slackware, but was broken for Debian and deb-based distros. The reason, the distro patches
The PPM (GtkDialog app) worked well with Ubuntu and Slackware, but was mostly broken for Debian, and it drove me mad several times and was trying to simplify the dialog to avoid the most nasty bugs
So I do believe when people say that gFTP misbehaves even though I can't reproduce the issue myself, and chopping the code is the only possible solution
I can help in testing.
You can test the latest git revision and provide valuable feedback. It the issue persists, I'll disable the cache for the FTP protocol
Something like this every time you want to run a fresh version
git clean -dfx
./autogen.sh
./configure --prefix=/usr
make
./src/gtk/gftp-gtk
Some significant changes happened for 2.9.0/1, mostly fixes for FTP... gftp supports broken servers it shouldn't really support, that's what makes it an alternative to filezilla, it works with more ftp servers, but support for dead platforms cannot be confirmed (Novell, VMS, MVS, Cray, EPLF)
The reply to the SYST command can't be trusted either, but what you're seeing is probably an issue with threads and stuff that doesn't currently happen in my machine
./configure: line 9281: syntax error near unexpected token `newline'
./configure: line 9281: `PKG_CHECK_MODULES('
pkg-config --version 0.29.2
On second run from git clean... I could compile successfully.
While running for the first time, there remote directory display is fine. And on third run it was showing date as 1970/01/01.
I initially cleared the folder ~/.gftp/cache and it is still empty.
Please advise what to look for in trace. Or else I shall send strace output text file (920 KB).
This might be useful.
While compiling the following warning messages popped up. As it has references to directory listing...
gtkui.c: In function ‘_gftpui_gtk_thread_func’:
gtkui.c:235:5: warning: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
235 | write (thread_data->cdata->request->wakeup_main_thread[1], " ", 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gtkui.c: In function ‘_gftpui_wakeup_main_thread’:
gtkui.c:176:5: warning: ignoring return value of ‘read’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
176 | read (request->wakeup_main_thread[0], &c, 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC gtkui_transfer.o
CC listbox.o
CC menu-items.o
menu-items.c: In function ‘save_directory_listing’:
menu-items.c:120:3: warning: ignoring return value of ‘getcwd’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
120 | getcwd(current_dir, sizeof(current_dir));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
menu-items.c: In function ‘savelog’:
menu-items.c:332:3: warning: ignoring return value of ‘getcwd’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
332 | getcwd(current_dir, sizeof(current_dir));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A simple change in folder name correct this date issue.
When the Date displayed is wrong...
If we are in root folder of the Server, just by clicking at the .. (double dots) appearing in the top of the folders / files list will show the Date correctly.
If we are inside a sub folder - may be /folder1 Adding a slash /folder1/ in the Server side folder name will show the Date correctly.
Hope this will help in correcting the issue.
gFTP 2.9.1b Unlike previous versions... Loading directory listing / from server - displays Jan 01 1970 for ALL files in Remote folder. and after changing the folder... Loading directory listing / from cache - displays the correct Date / Time for ALL files in Remote folder.
After emptying the folder ~/.gftp/cache, this error vanishes for some time.
With gftp-text