FreeCommander Forum

Can you give me a link to download the version with the bug fix (so I can test it) or email it to me?

- and did you try turning off the file display as well? You might find that drops another 5 seconds off - or even more... Windows isn't that good at doing very fast screen updates, I found this out ...

..and it's still doing it.. Even on a relatively small directory ie the current one I'm doing has 4190 directories and 56900 files the sync (not the actual file shifting, just the report) takes a looonnnggg time. And thats with just using the timestamp and file size to see if files are equal.

Why ...

If this was added, it should be optional (ie set in the FC preferences) - ie it's the LAST thing I'd want happening when I was copying files, as it would slow everything down a lot...

I would hazard a guess and speculate, that because Vista has lzw support already built into the operating system, that somehow the OS is doing a read-ahead cache trick and trying to interrogate the content of the .zip file in an attempt to increase performance for when the user wants to access the ...

..which is funny as I have tree view on and am still not getting the delay...

yep, in the root directory - and over 300gb of zip files.. Still no delay like you are getting!

Have you got another machine to try it on with the same files?

Ian

I just had a go at doing that - I opened a directory with a stack of zips in it - ranging from 10gb to 50gb in size (yep, my big backup zips) and many 100,000's files, then got out of FC and back in again.

Made no difference - was still fast! So there must be something happening somewhere on your ...

ie just trying to delete a big directory across the network.. It's been over 40 minutes so far and I've still got the "preparing to delete" box up.. Any file manager with it's on delete function (ie Nortons NT one) would have actually finished the delete 20 minutes ago and would not have even gone ...

Note: This topic has been moved to "Feature Requests". -Dreamer

After you have done a synchronize (ie hit the compare button, then the synchronize button) FC automatically wants to do the compare again.
Given the initial compare might have taken a long time (the one I just did was about 30 ...

I find it semi ok - if you click on it in the middle of the panel getting the sizes, it seems to miss the click some times, or even if it gets it (and cancels the size calcs) it can take a loooong while to happen. I've found it's best to go to a small directory, let it finish on that, then hit the ...

..and if it isn't that it must be something else slowing it down, as it's running a lot slower than it should (I have a vba macro that will do a sync faster!) when it is only using the size/time stamps..

Ian

The delete command suffers from the same sort of problem that the copy command does - it is using the windows api call to delete a directory tree,

The trouble with this is that it first tries to list the contents. On a local drive this can be very slow, and across a network (even my GB one) it can ...

Not sure is this can be classified as a bug - but when doing a sync the file names flash past very fast in the status bar after it has done the preliminary scans. I suspect that this might be slowing it down quite a bit - particularly between two big directories..

nah, not one of the developers, though am using it a lot and trying to help out a bit! :-)

That's a lot less files than my normal machine (the one I'm using right now) as I never have less than 2Tb in it, and sometimes 8 physical disks.. Don't know how many files at the moment, but it was well ...

I don't think this shouldn't be in feature requests area (as it really wouldn't be a 'feature'!)

And the problem is something on your system, ie I've tried FC on quite a few computers and haven't had that problem. Turn off your virus checker and try, that's the thing that normally kills system ...