network drives' zip extraction takes too long in WinXP-SP2-

[lakeland]

Hi,

client=win xp sp2
server(network drives)= win xp sp1
no firewall both

After upgrading sp2, extracting or testing time of network drives' archive that contain tiny & many files extremely increased.

There are no problem when using SP1 & SP2 with external program(ex.winrar)

Thanks for your help,

[Sheepdog]

There are no problem when using SP1 & SP2 with external program(ex.winrar)

Try to use unpacked version of TC.

sheepdog

[lakeland]

Thanks for reply.

But it didn't work.
After upgrading sp2 network drives' browing speed greatly improved as fast as local drive. But TC's internal zip may have some problem with sp2.

i'll stay patient.

[ghisler(Author)]

It could be caused by the speed limits added by Microsoft to TCP/IP to slow down the spreading of e-mail worms.

[KarlK]

Hi there...

I can verify this problem here as well!
It's _really_ weird though...

Here's what I've found out:

Unpacking zip-files from a network-drive gets very slow, if:

- you have a XP system with installed SP2 (270mb full version) or if you used a slip-stream CD with integrated SP2 (which normally is the same 270 pack just included on a xp-install cd!)

- you either use total commander x.x or windows explorer's in-build zip-feature and copy&paste out of the zip-file on the network


----------

Unpacking zip-files from a network-drive works 'normal', if:

- you use a machine where SP2 got _online updated_, which means the update-service just downloads needed parts for your specific computer. This is just an amount of about 80-100mb instead of the 270 mb offline install version!
At least with my tests it happened that an online updated SP2 machine had no problems in opposite to the other SP2 computers... !!???! Really weird though...

- you use WinRAR to open the file on the network and extract it to a custom path you choose on your local machine!

----------------

general notes:

- it doesn't matter if your network computer is also SP2 or still SP1. As soon as your local machine is SP2 (offline install!) and you try unpacking a zip-file from the network the problem occures and unpacking gets sloooooow if you have a zip-file with some more little files in it!!

- the problem is not related to that 'hotfix' which got released shortly after SP2 from MS. (that loopback fix I mean...127.0.0.1 addresses etc...!)

- the problem also does not have anything to do with the newly invented 'connection limit' to prevent viruses etc. from being spread to fast in SP2...

- the problem seems also not to have anything to do with total commander itself...as it occures when using windows explorer as well!!

- there seems to be a difference in the way winRAR copies files to the way of windows explorer and total commander...
as with winRAR the problem does _not_ occure (till now!) It works fast and flawlessly!

- the problem seems not to be a (faulty) 'registry-entry' or value to change (back) or edit in SP2...(I guess I could test that one out pretty good here)

Hope this helps finding the 'bug' and fixing it (fast)...
It's really annoying to wait for network-zip files to unpack/pack _that_ slow since SP2 now...!

Bye,
Karl

[Clo]

2ghisler(Author)
Good evening,
¤ I've a similar problem for a while between two PCs under Win 98SE (Fr). It's about to unpack in a network dir. and / or change files in an archive on the network drive ( U: ). Example :
A is the server - B is the workstation where the physical HD of the network drive is installed ( D: ) …just beside !
Handling : change files in a ZIP archive
A>>> files to copy in an archive >>>B>> Archive open= very slow; even a freeze time; the same in background.
B>>> files to copy in an archive >>>A>> archive open=normal.
It's a bit better for WinRar archives, though abnormally slow.
I had launched a thread a long time ago about that : "Who had worse ?" with precise times for slow copying operations in my post. I couldn't find out that thread from the Search, but I found out the URL in an archive at home…

- Following competent friends, it seems that sometimes the TCP/IP feature damages/changes itself in "B". When restored, all works normally, but the problem comes back after a certain delay; may be one day as well as several months

- Last points :

1. There is not any virus-scanner in these PCs
2. The way in which the server / workstation boot does matter. When booting the server, an optimal certain point of Windows loading is needed before to launch the workstation-boot . To wait that the server has loaded the whole Windows doesn't prevent that the problem should occur.

 Best regards,
Claude
Clo

[ghisler(Author)]

2KarlK
It may be caused by a background virus scanner. The difference between unpacking ZIP and RAR is the following: In ZIP files, each file is compressed separately, in RAR files, all files are usually packed together (solid archive). TC unpacks a zip like this:
1. Read directory of files
2. Start loop:
3. Open archive
4. Unpack a file
5. Close archive
6. Go to 2

Some virus scanners seem to scan the entire archive each time it is opened, which can take a very long time on network drives. Better scanners use a cache and scan the file only on the first access if there was no change (they monitor the file system).

If this is the case, then unpacking RAR files with Total Commander's internal unpacker should also be faster than unzipping. Can you confirm this?

[KarlK]

Hi Christian...

Nope! That's definitely _not_ the case with the problem...
Sorry that I didn't write about that in my first post to define it even more in detail...
So here it is now:

- There's _no_ virus scanner installed on any of those machines...

- Unpacking zip-files worked _perfectly_ fast with XP SP1 right before!
(no matter if using total commander or win explorer!!!)
Directly after SP2 (270mb version) it slowed down like written above!

- The difference with winRAR is _not_ that I used a rar-file instead!
Of course I took the _same_ (test)-zip file I also had when using TC or win explorer! So I just used winrar-gui to unpack a ZIP-file here!
With winrar it works as fast as it used to be (with SP1)...
(Of course I know/knew the difference between zip and rar-file-structures)

- I will try the next days what will happen if I use winACE instead of winrar to unpack that (test)-ZIP-archive... Let's see if it's slow or fast with that then!

- I will do more tests these days with .rar and .ace files just to see what will happen with those over the network:
IF it works fast...this might be a hint that the problem might be connected with the internal zip-routines implemented with windows itself as well, maybe! And...
IF it's slow...it might be another hint for a general network-whatever-problem which has changed since SP2...(but on the other hand this wouldn't explain that the problem is not occuring with this online-updated machine I have here though!! Hmm...)

- Of course it's also _not_ that zip-file here! I tested several files already to hunt down the way of archive-files where you can see the problem the easiest way. I packed own zip-archives for further test-reasons etc.etc...
At last I just took _one_ zip-file as my 'test-file' which I use to verfiy if other actions I try to solve the (weird) prob will help or not!

- There's also no firewall and/or network-NX options (max. number of connections at the same time - security feature since SP2) activated with those machines I test this on.

- The _only_ really weird thing is the difference I wrote in my last post as well: That on the other machine - where I did the SP2 install using the _online-update-service_ which downloaded 'only' 80-100 MB for the SP2 install - zip-unpacking over the network works without any problems! But with _any_ other machine either using a slip-stream XP SP2 CD install _or_ the 270 offline install package it does _not_ !!!??? Hmm... Really weird, or what!?
(Although I need to check out this 'online-updating' on a second machine as well to be really _sure_ that it will work after that every time...)

Just for the records I repeat:
I'm quite sure that it's _not_ a TC bug or something...but more a win-system thing since SP2 concerning 'anything' with the handling of network x-fers....but I can't come closer to the _real_ point which causes that beahviour...

But maybe these posts will help other people here to track it down and to find a _fix_ for that! As it really annoys me a bit!
(And it's more or less the _only_ thing which annoys me with SP2 till now though!! )) )

Bye,
Karl

...sorry for a little 'more' text this time!

[ghisler(Author)]

Did you try as a I suggested (unpacking a RAR with TC)? Is it as fast as in WinRAR?

[KarlK]

Hi Christian...

ok...finally I tried the following...

This was the 'setup' for this testing:

- used the contents of _one_ and the same zip-file to produce several other packs from those (-> .rar etc...)
- Both machines where I unpacked those test-files from one machine over the network to the other had SP2 on it!
- All testing was done using tc603a (internal unpacker routines)

Results:
- unpacking the .zip over the network => slow unpacking with SP2
- unpacking the .zip over the network (using windows explorer and its internal zip-routine!!) => slow unpacking with SP2

- unpacking the .rar over the network => fast as normal!!
- unpacking the .ace over the network => fast as normal!!

...please remember: the contents of the all archive-files were the absolutely same as in the .zip file!

- unpacking the .zip over the network with SP1 machine(s) => FAST as it used to be always before!!


So...are we smarter now!? Hmm...

Bye,
Karl

...very curious about the possible fix meanwhile!

[Andreas Strahm]

Hi Christian

Browsing the network with TC is also broken in SP2. There is a lag each when TC tries to refresh the display of a directory.

The delay happens while browsing
- the workgroups
- the content of a workgroup
- the top level of a network share (e.g. \\pc\c$)

Browsing using the explorer does work without delay.
If I change directly to a subdirectory of a network share using "cd \\pc\c$\windows" there is also no lag.

This behaviour drives me crazy. It should be fixed ASAP.

Andrew

[Sheepdog]

I don't think it is SP2 related. Here I mentioned the above described behavior. Unfortunately there was no reply.

sheepdog

[ghisler(Author)]

- unpacking the .zip over the network => slow unpacking with SP2
- unpacking the .rar over the network => fast as normal!!

This is indeed an indication that the open/close file process is slow on XPSP2, while the actual data reading is fast. I will check whether I can modify my unzip functions accordingly. But I still don't understand why Microsoft did this, especially since it affects their own unzipper too.

Browsing the network with TC is also broken in SP2. There is a lag each when TC tries to refresh the display of a directory.

This is usually caused by a multi-homed network, e.g. when using vmware with active virtual network adapters, or when binding TCP/IP to the network card of the DSL modem (it must NOT be done, since TCP/IP is already bound to dialup networking).

[KarlK]

Hi Christian...

well, it seems to be something like that I guess...
As you said...as it's the same with MS's own zip-routine as well!

BUT:
As I also said in my first post...
What's _very_ weird might be that it seems that an xp system being updated via the _online_ function instead of using the offline 270MB SP2 pack does _NOT_ slow down that way!!

So _where's_ the difference here now!?

(Although I'm still trying to verifiy that behaviour with another online-updated machine soon I hope to be really sure that it behaves that way in opposite to the offline update)

Bye,
Karl

...but maybe you can already find out more as well!!
Crossing my fingers at least! As the slowdown _really_ goes on my nerves meanwhile! :-//

[ghisler(Author)]

What's _very_ weird might be that it seems that an xp system being updated via the _online_ function instead of using the offline 270MB SP2 pack does _NOT_ slow down that way!!

Maybe Microsoft didn't replace all files? You may try to compare the two WINDOWS and WINDOWS\SYSTEM32 folders of the two machines (if they are on the same network) with commands - synchronize dirs to find out which files are different.