This problem is still present in version 9.5.2.0.3660.x86
This problem is still present in version 9.5.3.0.3728.x86
Write to GPSoftware, not this user-to-user forum, if you're still seeing the problem and want to nag them.
I has the same problem no matter which version I use. Do anyone report this and get an answer? This happens when I try to zip many files into one zip. Large files seems to be work good. And yes - i see that temp file is created again and again and zip process going endless. What is funny - that zip what is created first time works but still is difficult to stop that endless re-creating zip archive.
Something is wrong, for sure, with batch processing when lot of files are copying to ZIP, even if is uncompressed (maybe when filenames are longer or has some specific characters, i don't know). 7z works good but I want to use Opus for creating zip archives in all cases, not only for single files or small archives. I think that my confirmation of that problem should force someone to look at. Using temporary files when copying is even worse (because i don't see that temp what is creating again and again) and turning off batch add makes operation very slow for small files.
Has anyone actually reported this to GPSoftware? If you want it looked at, report it through the proper channel.
I don't believe that no one report that bug if is almost 2 years old. I find that post by searching this forum for zip problem (according main rule - search before posting) and after look at fist post date and people who confirm problem, I suspect that problem is already reported. The problem is that there is no "bug site" where I can check that problem was reported or not. I just don't know how can I prepare 500 MB of files for reproduce problem but if I'll find a method - I'll report a bug.
I'm still not even sure how to reproduce this problem, to be honest.
If it's difficult for you to find 500MB of files that reproduce the problem then it's even more difficult for someone else to reproduce it from just the information in this thread. I have never seen the problem, I'm not sure exactly what to look for or what to do, and I'm not sure if my configuration will even trigger the problem if I did the right thing.
If someone gives step-by-step instructions that reproduce the problem for them, I'll see if I can reproduce the problem on my machine. If I can, I'll send a bug report myself. Without that, I'm shooting in the dark.
Instructions should include what to zip and, importantly, how to zip it and what configuration was used. ("How to zip it" as in, which actions you perform to create the archive. For example, dragging files into an existing archive can be very different to right-clicking a folder and choosing the menu item to turn that folder into an archive. The type of folder/directory which the files come from can also matter a great deal.)
I would not assume it has been reported to GPSoftware because there doesn't seem to be agreement in this thread on exactly what the problem is or how to trigger it, and without those kind of details I can't see anyone sending a bug report.
Ok, if you are ready then I prepare really crazy zip archive that shows you what is wrong/strange in Opus.
This zip has is created by 7z and has over 1GB of data - lot of files created by visual basic - random files with random names. Nothing interesting is inside any of them except that they are not empty (random bytes).
Opus needs really long time to preparing batch (2 minutes or more) - but remember that this is only example because i can't upload files that i cannot spread (copyrighted photos that I have problem with). Real files that makes looping in zip needs short time to preparing batch but still effect after is similar.
All settings in Opus are default. Try to compress that files (after unpack) with no compression. And look what happens after all files are added to archive - tmp file is creating again and again (I don't know in this case how much times because i kill process after second loop - normally it can be even forever and only killing opus process can stop looping).
Important - that files are prepared only for test, so Opus is crazy not because they are strange or too much of them etc. I have, for example, three directories that can compress separately but can't compress them all when I put them to separate directory. Size of archive does matters as I see, that's why I upload over 1GB zip.
Other strange problem is that I must use filezilla for upload that zip because opus transfer is freezing at the end of that file.
Good luck.
Just want to let you guys know that for me, zipping teefan's 1.3GB file works perfectly in both "Lowest/Fastest" and "Highest/Slowest" zip settings. No 2 minute delay either.
(Also, just for the record, I use DOpus daily to zip files ranging from 10MB to 1.5GB, though it's just single files, no deep paths.)
That's good but as we knows, many people have many configurations - based on different operating system versions. And as I know zip can be processed different on different OS version. My operating system is WinXP SP3 32 bit (up to date).
Compression method is mark whole directory and choose "Add to zip" from RMB context menu.
Here are my zip options:
Maybe that helps.
Using Add to Zip... from the context menu, on the data you provided (thanks!), I can reproduce what you're seeing. (Or, at least, it takes several minutes to initialize the batch operation when it shouldn't take more than a couple of seconds, if that. I didn't bother waiting to see what else happened as that was clearly wrong by itself.)
If I instead use Add to testob.zip from the context menu then it seems to work fine.
Do you see the same as me? i.e. Is the problem only when using Add to Zip... to show the zip options window first, and not if you use the other menu item which creates the zip directly without showing the options window?
The "add to filename.zip" shows me window with options but without setting name of archive. But preparing is much faster, just few seconds.
And yes - this option (add to filename) not only faster preparing batch process but also finish operation with success! I never expect that can be any difference between this two methods except filename.
Just a little offtopic - maybe better method to improve Opus is believe what people said and check something that someone report over one year ago instead of say that someone is nagging (like this guy before me) or looking for antivirus problem? The main problem with AV question is that if you have AV then always someone says that is because of AV software. If you have no AV software, then someone answers that should be virus. I'm always scarry about answering that AV question, because in most cases discussion going into wrong direction instead of focusing on main problem.
By the way - please check also what happens when you upload that file into FTP. As I said, I was some problem with finishing operation (not with transfer itself). And it's not first time.
Good luck.
By the way - can I delete that big file from FTP server?
Cool, thanks for confirming. (BTW, if you see the options window there as well then you must have Opus set to always ask for zip settings when adding to zips. That's why that was different for us, though it's not important.)
Excellent, thanks.
I will pass on the details to GPSoftware. I know they already have plans for the zip code so addressing this will fit in with them.
I never said I didn't believe anyone; but nobody had ever given me enough information to reproduce the problem myself, and it seemed like nobody had or was ever going to bother reporting the problem to GPSoftware (as far as I could tell, and certainly not with enough information for them to reproduce the problem any easier than me or anyone at the forum could).
Those are two things I cannot do anything about except to urge people to report the problem properly and/or provide more detail here, which is what I did. Meanwhile I was apparently ignored until now, when you provided the detail that was needed all along. Now that I'm able to reproduce the problem I will report it for everyone else.
What more could I possibly have done except try random things all day until I stumbled on the answer (if I did at all)? If I did that I wouldn't have time to do anything else.
Also remember that anyone answering questions on this forum, including me, is doing it in their spare time to help other people. I think we provide very good support (in general) but we're not the official support channel. If the community at this forum can solve someone's problem -- and it almost always does -- then that's great; if it can't then the problem needs to be sent to GPSoftware to see what they can do. (Or which questions they can think of asking, which was the real problem here in the end.)
I don't think I said anything was definitely caused by AV software. There is always the possibility that something MIGHT be caused by it and that means it is always worth quickly trying with it disabled to rule out that possibility. It doesn't take long to do that while it can be a huge waste of time to investigate a problem that turns out to be due to it.
I'm not asking of anybody else anything I don't do myself. It's something I do when diagnosing problems on my own machine.
It's especially worth trying with anything involving archives because anti-virus scanners can scan inside of archives and can really slow things down if something is triggering them to scan the archives over-and-over (for example).
Before I start uploading gigbyte files to random FTP sites in random ways, could you provide some more detail? e.g. How you initiate the transfer (drag & drop? copy & paste? select and then click the Copy button on the toolbar?), what type of FTP site it is (normal FTP? SFTP?).
I'll try anything in an attempt to reproduce a problem but I don't have time to try everything, if you see what I mean.
Go for it, I've got it and have kept a copy in case GPSoftware need it.
This is paid server (one of leading in my country), normal active FTP connection in binary mode (sets as default) and copying mostly by pressing own shortcut (F5) for copying file. I'm always using separate listers (never dual) in power mode (if it's important). Also my upload speed is about 4MB/s (what is over 30Mbits so it's not a slow connection).
And that is for long time until I press Abort.
On second server, binary mode but passive, transfer is completed without problem. I know that may be something with server but still FileZilla can copy this file to the same server without problem, so maybe is worth to check.
I can prepare FTP for test.
Do you need any additional info about that FTP behaviour? If you have prepared FTP for testing - let me know by PM and I'll make access.
If you can give me access to that FTP server to test with that'd be great, in case it is related to an interaction between Opus and the server software/version. Send me a PM with the details.
I thought of a couple of other things worth a try if you have time, although if you want to wait to see if I can repro the problem against the same site then that makes sense. If I can repro the problem then I can check these things myself.
[ul][li]Go to Tools -> Output Window -> FTP #1 (or FTP #2 if the site is set to log to the second tab) and see what the FTP log says, if it's still there from when you last tried. It might have an error message.
[/li]
[li]After the transfer fails, if you reconnect to the site is the full file there or is it incomplete? If it's incomplete, are you able to use Opus to resume it or does it still get stuck at the end?
[/li]
[li]If you let the transfer begin and do a few meg of the file, then abort the transfer, then do it again and resume (not overwrite), does it complete? i.e. Does it only fail if the entire file is sent in one go?
[/li]
[li]Presumably uploading a small file to the same site works fine?[/li][/ul]
- What FTP log says I show before (small image).
- File looks like be complete but I not check is damaged or not.
- Small files works ok.
- I send you PM with FTP access.