sftp worked just fine for a while and then all of a sudden for no apparent reason it started giving me problems. i would click the SFTP button, the window would open, no files would display on either side, would say not responding. if i waited long enough the files would show up but it might take 10+ minutes. if i click close on SFTP the whole program was killed/died. This went on for weeks and i just worked around it but i would spend a few mins thinking and looking what might be wrong. i tried all the usual suspects more than once and not help.
tonight i tried it again and same problem happened. i don't know what made me think about it but here's what fixed it.
i do a little of everything, programing, server admin, dish washing, catching chickens, etc 😉 i had my download directory set to a directory that had a ton of files in. not just in size but also in quantity. I created a directory with nothing in it and set it as my download dir. Clicked SFTP and boom all is happy in the SFTP business.
i can only speculate but when SFTP opens it must read the download directory and maybe recursively. When it quit working i must have added that last file it took to break SFTP.
Maybe that helps someone and maybe it don't but i am not charging for the information so don't complain haha
How many files are we talking about?
Brian
in the top download directory 150 +/- files and directories that total roughly half gb.
Sub directories of above: 46,528 files, 1,618 directories.
If it helps this is what I am running:
XP Pro x64 sp2
AMD Athlon 64 x2 dual core 6000+ 3.00 GHz
2 GB ram
2x 150 gb seagate barracuda 7200 rpm disk >> raid0
don't get me wrong, i am not complaining. i just thought knowing might save someone else a hassle.
for the record i been using absolute telnet since about 2003-2004. Can't start my day without looking absolute telnet or ol' Black Betty is what i call her....She's so rock steady, She's always ready! bam-ba-lam.... maybe that should be in a song 😉
Thanks for the details!
I'm not accusing of complaining, but in every question, comment, or complaint, I always to to find ways to improve. I agree there does seem to be an issue when large numbers of files are involved.
A directory with *thousands* of files in it can sometimes take a bit of time to display (particularly if it is the remote directory), but the local one should not, especially with only 150 files/directories in it. I've been doing some testing with large quantities of files and I've found a few optimizations that are going to help. I'll have to get you to try it when I'm done.
One quick question, though.... If you set the download directory back to the original location, does the problem return?
Brian
i deal with "users" day in and day out. i just wanted to make sure you knew i was not making something out of it. the last thing i want to do is act like some people think they can treat me. i have no agenda except just informing.... and passing the time of day 😉
Ok, strange thing. i just now changed the download dir back to what it was before and it works fine. iow, NOW no matter what dir i set the download dir to it WORKS.
i sense you know what makes it do this and it may not be number of files. good for you either way.
i love puzzles
I'm seeing the same problem. When viewing a folder with a lot of files (local or remote) AT takes forever to build the list of files. You can sometimes see the scroll bar thumb slowly decreasing in size as the files are added to the list.
Did you see my other post about how to fix it? Windows' List Boxes take forever to populate if you don't turn off redrawing while populating... Here's what I said in another thread:
I'm not sure what language AT is written in, but if you're using a standard Windows list object, sending a WM_SETREDRAW message to the control before (with FALSE for wParam) and after (with TRUE for wParam) building the file listing can reduce the amount of time by several orders of magnitude. At least the portion of building the list that occurs in Windows APIs anyway.
That technique has worked very well for me. Long list boxes go from taking minutes to build to fractions of a second.
I thought I fixed this once, but I think that might have been one of the things I lost in the "Great Hard Drive Crash of 2009".
I'll take another look.
Brian
I've been hard at work of the last few weeks trying to beef up the SFTP dialogs to handle large numbers of files. Boy was it a mess. Not only did it take a long time to process the directory listings, but the app would appear to hang while it was doing it. I've put a lot of work into making the SFTP dialog much more forgiving and responsive, regardless of how large the directories are. I've tested it with tens of thousands of files, and it still works well.
I've posted the new version to the beta group. Please join in there to get the new version and join in the conversation:
http://groups.yahoo.com/group/celestial_beta
Brian
