How can I disable directory caching in filezilla 3?

[botg]

<Link removed>

[tenaya]

Hi I'm new to this forum and I like FileZilla. But also I find the caching behaviour annoying. I can't believe there is a real benefit with this caching - today's availlable bandwidth is not a problem anymore. Now, when using FileZilla you never know what's going on the server; especially if two or more clients communicate via the same folder. In the past, most of my colleagues used FileZilla but now most of them either switched back to Total Commander or are now using FireFTP. The only reason is the caching stuff and the herewith linked uncertainty in browsing server listings. It would be a pitty, if an otherwise strong and feature-rich FTP client, what FileZilla is, will fail at the end only because of such a little but important function.

I would like to see disabling chaching in future releases of FileZilla. Does the above link mean there will be soon a new release with the possibility to disable caching?

[FalconFour]

forget it, they now what you need better than you

This.

I, like many others in this thread, googled my issue and was led to this thread. What did each of us get at the end of our journey? Stubborn developers telling us that we're wrong, go away, this is how it will always be, because this is how the developers sleep at night.

Well, if that's how you want to handle your project, then fine, I'm keeping my eyes open for another FTP client. This TOTALLY WORTHLESS "caching" function causes a lot of headaches for people using FTP in a wide variety of scenarios. The fact that the cache is persistent between disconnect/reconnect is bad enough. F5 should clear the entire cache and cause subsequent folder changes to re-request the directory listing, but it doesn't.

Caching should not be used in FTP. At all. Changing a directory should send a command to the server to show that you're still active, as well as see the latest files on the server. It doesn't take but a fraction of a second to get the directory listing.

Why is it so much to ask that we merely get the option to disable caching, instead of stuck-up replies like "I'm too lazy/stupid/incompetent to do it myself, so here's a link to the source code, do it yourself"? How about a "Thanks for your suggestion, I'll work on it for the next release"?

[boco]

The entire engine expects a working cache at all times.

If I could, I'd disable it as well. But the cache is important for the queue operations, I guess.

[Bullduck]

I'm here because the cache has been driving me nuts as well. When I do work on a remote server I jump back and forth between Filezilla and putty and the fact that the changes I make in putty don't reflect in filezilla unless I remember to refresh sometimes cause me pain. It seems silly that there is no way to disable the cache for those don't want to use it. Also the fact that folder contents don't populate automatically is a bit annoying. I get the impression that this software was designed to use on dial-up.

Anyway, I commend the developers for creating the software but the apparent lack of interest in the user feedback on caching is very disappointing. I was sufficiently frustrated today to look for alternatives and am going to give to give WinScp a try. It's free and zips along while showing all folders and displaying what is, not what was. I'll be back in the future to see if the problem with filezilla has been corrected. cheers...

[tateu]

No. The entire engine expects a working cache at all times.

Couldn't you just change CACHE_TIMEOUT (directorycache.h) to static and set it = 0, so that it always thinks the cache has expired and refreshes it? It seems to be working in my test version.

[botg]

I think that would also force a refresh on some engine-internal operations, so not a good solution. Better request a refresh from listing operations started from the GUI, there's already a flag for that you could use.

[eddiw]

I have also problem with this cache function and I did not get happier while reading this thread. Why having a developer forum when the developers not listen and are really arrogant and throws the source code at you, and practically says "Do it yourself moron".

Why why why?

I am not saying what to do or not, but I'm asking for more politeness. Can't you see that you are loosing users when acting like this?

(English is not my native language, that's why I'm writing as I do..)

[boco]

Various mechanisms inside FileZilla depend on a working cache, so it cannot be easily disabled (I never used cache in v2, it annoys me, too).

But there is only one developer and not much time.

[jeffreyf]

I was just recently bitten by this....
I am using this to check a vendor's ftp sit and I returned to a subfolder to check if any files were there.....and from the last view of that folder, there wasn't....and I was shown an empty folder....there were files on the site. Fortunately, this wasn't critical.....

This should be a settable option on by default....but it should be optional.

[Caspan]

I don't want to bump this thread again but want to add my 2 cents. I love this FTP software, it is the best out there... there are things in this product that I sent to other developers and they laughed at me. Stuff like directory browsing synchronization, ability to filter out svn and src folders so that uploads of a directory with source code are not uploaded, Filezilla added these themself. This is hands down the best FTP client out there. Now on to the matter the caching also drives me nuts but only for the local side, I understand 100% why when some other user changes files on the server until I refresh the server directory that those files are not seen, this is typical of a non persistent connection. When I open the server directory it gets asks for a file/directory listing and then returns that to my client and then the connection is done until I send another command. So I understand that I need to ask for the directory again to see if any files/directories have changed since I last loaded the directory. Stuff like uploading a new file would cause a directory re listing. So I get 100% how that functions for connections to the server, but when you have an OS that the client has a persistent connection to why can the local directory not keep up to date? It drives me nuts that every time I create code or images that I have to refresh the local directory to see those new files before I can upload them. It seems very trivial to just hit refresh but it really does add up when you are adding a thousand images to a directory one at a time after they are created uploaded and verified and more to the next. The constant refresh is very annoying. Is there any reason why we cannot keep the local directory constantly updated I know windows has hooks to notify an application that the contents have changed so that apps can keep a consistent listing for the directory. I have read there is only one developer and this is not just a simple lets just add a switch to stop it from doing that. But please realize this is a very important function for hard core users that use this for day to day website development.

[Carstairs]

Don't want to be a burden, but it's hard to believe that it's 2013 now and even I'm having this problem. Seriously, fix this. Filezilla is great, but even the online File Manager for my website works better.

[Caspan]

I don't think anyone is listening!!! 1 person to many tasks....

[tedych]

It's 2014. Will this be fixed ever? I have gone through another journey of searching for a good FTP client and unfortunately the good FTP clients are too scarce.
The ONLY thing now (I gave up on many of my requirements for and FTP client) that is in my way of using FZ is the caching problem. I would have gone through the pesky, tedious and lenghty process of compilig FZ myself after the CACHE_TIMEOUT directorycache.h manipulation, but this is Not my job.

I thought, why is not FZ able to just flush the cache when Disconnecting from the server, and not just when exiting the program? That will do too. Whatever dependency the d**n "engine" has on caching, it is flushed when quiting the program; why isn't it possible to do it when disconnecting from the server, and the next reconnect we would have fresh directory listings??

Believe me (I'm stunned I have to mention that) - hitting F5 thousands of times per day isn't something a human would remember to do. And only once is enough to cause disasters.
Don't put web browsers on par with FTP browsing. Web pages are different story, also the HTTP is fundamentally different - it uses "hit-and-run" stateless connections.
I don't see why FZ cannot flush its caches when disconnecting from the server - this alone would be a big step ahead. A step that will return it to something FZ was in the past.
Actually caching for the current FTP session is not that bad. But FZ must flush the caches on disconnect (as opposed to program-exit).
Until this is fixed I can't switch back to FZ, ever. This is a critical issue for me and for almost all colleagues, acquaintances, friends, family et all.

[tedych]

It seems we'll have to look forever if this had been fixed.
At least once a year I give this a try, just to uninstall it the next minute when I see this bug hasn't been cured yet. Yes, it is a bug, very serious one.
I just can't live with this, it's a plain dangerous behavior! Too sad because the program is nice, but this one bug makes it plain unusable for anything other than a simple file upload-close-and-forget.
And F5 always refreshes both panes, reaally?! And I have to constantly hit F5 for Every folder that'd been visited in this (program) session (not just connection session) just to make sure it displays the right content?! Ridiculous. At least discard the cache when we Disconnect (end the server session) so the next connect would display the right content - keeping the cache only WHILE connected seems a good "deal".
I can't count the years anymore that this bug has been complained about.
If I program something, even free, I make it usable and sane, at the very least. I'd pay for this program if this, and few other small enhancements were to be implemented. Why not make a shareware fork? I'd pay something like $25 or so, given what others offer for slightly more.
A reasonable price and this program could become profitable to the author, and much better.