ZIP FIles As Folders

[rlkeeney]

I'm currently archiving a large project that is taking much longer than it should. There are a large number of zip files on the server that are being treated as if they were file folders. This is causing the archive to take an incredibly long time. So far I have not been able to determine what is causing this to happen. The server is a Windows. Exactly what flavor I'm not sure because I do not have access to it and the person who does is off site.



Has anyone seen this before? Do you have any idea what could be causing it?

 

[Harry_Redl]

Hi,



what does it mean "... number of zip files ... that are being treated as if they were file folders" ?

Does that mean that the .zip files are changed all the time? (files are added and deleted from the packed files ....)

If it is so then it means

a) you have to backup huga amount of data daily ....

b) if you are trying to compress that files again by TSM (compression enabled on server or client side), it may be CPU consuming task, the files may become even larger and you should observe delays as you have ....



Does this sound like possible cause?



Harry

 

[dustyp]

From the way he worded it sounds like TSM is opening the zip files as it would a folder and individually scanning and backing up the files contained therein.



I know the Windows XP user interface has built in .zip functionality that treats .zip files much like folders, but I wouldn't think that TSM would do the same thing, unless it is querying the O/S about the .zip file and Windows is telling TSM that it's a folder.



I could see how this would slow things down, especially if one were doing client-side compression, as each time a .zip file was backed up, the O/S would unpack each file, TSM would then repack it, and send it to the server. Furthermore, when doing a restore, the files would come back as files in a folder, instead of a single .zip file, which could potentially blow through all your disk space, causing the restore to fail (and perhaps other things).



Even if the zip file doesn't change, checking the status of each file inside to see if it was modified could be a time-consuming task, if done one at a time.



Sorry I don't have any helpful information, but if this accurately describes what's happening, maybe someone else can shed some light on the situation?

 

[moon-buddy]

I have not seen this happening on my systems - where there are a lot of zip files.



It looks more like the files are being modified "on the fly" while an archive is being done.



Would it be possible to stop all other running process once the archive kicks in?