So, running Opus 10.0.2.0 64bit on a temporary Win7 x64 laptop for some weeks now (temporary has lasted longer than I'd have liked)... and I've chosen to redo some buttons using native Opus facilities rather than install some of my other personal licensed apps on a temp system.
Can't for the life of me figure out what the syntax goof is in trying to do this, but I've tried a bunch of different syntax to create a zip file:
from all of the current folders items
in the PARENT folder of the current folder
using the current foldername as the zip file name
withOUT the archive dialog appearing...
So after a bunch of different attempts, I settled on THIS which I'd have thought should work (minus the fact that it STILL calls up the dialog):
@nofilenamequoting
dopusrt /cmd copy file=* createfolder "{s|nopath|noterm}.zcb" addtoarchive=.zip,nosplit,nofullpaths to ..
...but the buttons got some severe problems...
1.) Still produces the dialog, really want to suppress that...
2.) Since the dialog DOES come up, it seems that my "to .." argument is being ignored. It's showing the correct zip filename from the createfolder control code - but still to be created in the CURRENT folder instead of one dir up
3.) If I accept the dialog as is, Opus doesn't something strange... it creates the file in the current folder like the dialog says it's going to, but INSIDE of the zip file is ANOTHER file with the same name as the newly created zip file. Sometimes that "extra" zip file appears to be corrupted and Opus can't browse into it. Sometimes, it's much smaller (22 bytes) and I can browse into it and it's just empty.
Any thoughts about (?):
a) Adjusting the button syntax so I get what I want
b) What's up with the very odd behavior of the button? After having no luck with just the addtoarchive and "as" option (to pass the zip filename), I more or less just used the code Leo suggested in this thread... which with minimal change also creates this strange extra zip file inside of the regular zip file - even with the "to .." arg chopped off. Shouldn't happen...
So... the "extra" file inside of the resulting file appears to be a result of using the file=* argument. Probably wouldn't even happen if Opus was creating the target zip file in the PARENT folder as I intended to happen... but it seems that the initial (~temp) zip file being created is being added into ITSELF because of the file=* arg. If I change it to file=*.jpg then it ignores the initial zip file - or I could just drop the file arg all-together and select all the files first... but I wonder if this should be considered a bug or not.
Either way - still puzzled on how to get the syntax right to achieve what I want. I putzed around with minor variations for like an hour ...
Taking a look at other buttons of my own making for some guidance... I also couldn't get it to work in a way that makes intuitive sense using the createfolder arg for full path to the file:
@nofilenamequoting
dopusrt /cmd copy file=*.jpg createfolder "{s|..}{s|nopath|noterm}.zip" addtoarchive=.zip,nosplit,nofullpaths
This code results in the dialog coming up with what appears to be the path that I want... but then accepting it throws the following error window:
[quote="Directory Opus"]An error occurred creating archive 'filename':
The filename, directory name, or volume label syntax is incorrect. (123)[/quote]
I think the main thing is to use ARCHIVE instead of ADDTOARCHIVE.
There's no need for the dopusrt stuff.
The zip extension will always be added if a zip file is being created, so if you want a different extension I think you have to rename the archive after creating it.
Ah... ok, that's better thanks. Forgot we had the ARCHIVE option to use and that it behaved differently from the ADDTOARCHIVE option... forest for the trees sometimes.
Thanks again... and I'm happy to report, that while the following code:
@nofilenamequoting
copy file=* to "{s|..}" createfolder="{s|nopath|noterm}.zcb" archive=.zip
...when run on an XP box with 10.0.1.6 installed, results in a [b]file.zcb.zip[/b file being generated... the same code running on my Win7 box with 10.0.2.0 installed results in just a .zcb extension - without the trailing .zip extension.
A happy accident, or some undocumented tweak in the copy code in 10.0.2.0...?
Aha - that's exactly what I did on my 10.0.2.0... when I started trying to get things to work originally. And sure enough, I didn't make that same change on the 10.0.1.6 box yet. Mystery aborted...
Strange... I'm now trying to do a similar thing with just the "selected" files... and creating the zip file in the current folder. Based on where I arrived at above... I assumed the following should work:
@nofilenamequoting
copy here createfolder="{s|nopath|noterm}.zip" archive=.zip
But what I get is the intended zip file name... in the correct/current folder... but with only the FIRST of multiple items selected present inside the new zip file, followed by the message:
The same code works as intended on the other XP/10.0.1.6 system. Does any of the batch stuff related to zip handling work differently between XPx86 and Win7x64? I haven't "changed" any of that stuff myself. Going to see if there are any applicable options to mess with.
Also worth noting, when I've selected "folders" as the items to zip up, it's the "contents" of the first folder item that are being zipped up into the root of the new zip file...
To try and get something "functional" with minimum fuss, I abandoned my efforts to do things myself and tried enabling the Opus ZIP context menu stuff instead. I still get incorrect behavior that I wonder if anyone else is getting the same on 10.0.2.0...
If I turn on the "Add to Named Archive (immediately creates archive)" context menu option in Prefs... selected a bunch of folders, and use that option... the resulting zip file gets created successfully, but the item that was right-clicked on amongst the folder selections in order to call up the context menu gets it's contents added to the zip file - while all the "other" folders are placed directly into the zip file.
Since the commands above that I was originally trying to use worked ok on my XP system running 10.0.1.6, I tried the Opus ZIP Context Menu stuff on that machine as well - and found that this stuff ALSO works ok on the older system. I'm going to:
1.) upgrade the WinXP system from 10.0.1.6 to 10.0.2.0 to see if the new release BROKE these features, and
2.) reset my Win7 10.0.2.0 system to default Opus config to see if it's something about my config on this system that's somehow causing the issues...
UN-installed and re-installed v10.0.2.0 on my Win7x64 laptop... and the problems remain with both:
----- the built-in Directory Opus Context Menu item to create a named zip file (adds the "contents" of the RMB clicked folder to the root of the zip).
----- the raw copy command example below that WORKS on WinXP x86 system... but which produces the file 'already exists in destination' error popup below. A regular dialog driven zip file from a basic raw "copy addtozip" as well as the similar from the Operations toolbar Archive Files menu works fine.
About that last... in strikes me that Opus' behavior when explicitly naming the file in the copy command ala:
@nofilenamequoting
copy here createfolder="{s|nopath|noterm}.zip" archive=.zip
...seems to basically be acting as though Opus is trying to run a separate Copy ARCHIVE=single operation on each selected folder... and in keeping with that, each withOUT the implied keepfolder behavior of a multiple folder selection copy ZIP operation. If I select the 'Merge' option from the dialog this command throws... the "contents" of each remaining select folder in turn gets added to the zip file. So that all sort of makes sense when you look at it from that perspective... but it shouldn't be happening in the first place. It should be doing a multi-selection zip...
Can anyone reproduce both these behaviors running 10.0.2.0 on a Win7 64bit system...? I'm wondering if some default flags for this part of copy archive behavior got flipped somehow in the 64bit build of Opus...?
Sorry, was vomiting details as I discovered them... but at this point, I'd still imagine it all to be related in some way. I also only suspected an issue with Win7 x64 vs WinXP x86 simply because the version of Opus (last illuminati vs current ga) didn't seem to make a difference, and the difference in platform was the only thing I could attest the issue to. I'm otherwise just citing multiple points of apparent breakage of ZIP Copy functionality on this Win7 x64 box...
At any rate, as you say - one at a time then... I'll parking lot the raw copy command issue even though that's the one I really want to get working - in favor of dumbing the whole thing down to things that should incontrovertibly just work...:
Opus Context Menu:
[ul][li]I turn on the Enable Archive context menu option and turn on ZIP (.zip) item under the Add to Named Archive (immediately creates archive) header...[/li]
[li]I select three folders (folder1, folder2, and folder3), then right-click on the first selected folder (folder1) and choose the resulting Add To "folder1.zip" option under the Directory Opus Archives zip menu...[/li][/ul]
The resulting folder1.zip file has the "contents" of folder1, along with the actual folder2 and folder3 folders copied into the zip.
Enabling the Add single folders as sub-folders of new archives option doesn't alter this incorrect behavior... nor would we expect it to since I'm zipping a multiple folder selection, not a single folder. In any case, I flipped that option on and off several times and repeated the test each time to be sure - and while it certainly seems to be taking effect based on changes I see happening in the /dopusdata\ConfigFiles\archives.oxc file (the archive_context flags value is changing from 60<->61)... this option seems to be among the broken things on this system, as a true "single" folder zip tests always results in the single folders "contents" being added to the zip file instead of the actual folder itself...
...and again, all of this just "works" on the older XP system.
Does anyone else running Win7 x64 have the problem mentioned immediately above when zipping multiple folders from the same Directory Opus Archives context menu?
(EDIT: Re-reading what you wrote again, maybe I did misunderstand. (Why does my brain understand things better only after I've written a reply? ) See my next reply if so!)
[quote="steje"]Opus Context Menu:
[ul][li]I turn on the Enable Archive context menu option and turn on ZIP (.zip) item under the Add to Named Archive (immediately creates archive) header...[/li]
[li]I select three folders (folder1, folder2, and folder3), then right-click on the first selected folder (folder1) and choose the resulting Add To "folder1.zip" option under the Directory Opus Archives zip menu...[/li][/ul]
The resulting folder1.zip file has the "contents" of folder1, along with the actual folder2 and folder3 folders copied into the zip.
Enabling the Add single folders as sub-folders of new archives option doesn't alter this incorrect behavior...[/quote]
You selected folder1, folder2, folder2 and told Opus to add them to folder1.zip. That's what Opus did. That seems correct, unless I've misread something.
If you wanted each folder put into a separate zip, the context menu does not do that (and has never done that by default).
The Files to Separate Archives command on the default toolbars is probably what you want:
That runs Copy ARCHIVE=single HERE. Maybe on your XP install you edited the context menus to run that instead of the default command?
[/li]
[li]Windows 7, 64-bit, etc.
Honestly, I really doubt any of this is an issue of 64-bit vs 32-bit, or XP vs Windows 7.
Windows 7 and 64-bit may be new and exciting to you but they're all very old and boring to us. They will almost never be a factor in stuff like this. Aside from a few special places, the code is literally the same between the two versions (just compiled for different CPU types). We'd be talking a compiler bug or some really obscure pointer-size error in the code that somehow hasn't been found in four years and has no other effect other than to put files in archives differently to what you expect...
I'm sure there are much more mundane explanations for everything. (Configuration differences between your two machines in some cases, or how the commands work in others, both of which we should be able to work out and work around.)
That's especially true when I'm using the 64-bit version on Windows 7 and not seeing all of the same things as you.[/li][/ul]
Second attempt, after re-reading and engaging my brain a bit better!
Let's see if I'm doing the same thing as you.
I start with this setup of test files and folders:
I select the folders, right-click folder1, then choose Add to "folder1.zip":
I then go into the zip and turn on flat-view, and it looks fine (folder1 added as a folder, like all the others):
If you see something different, is it definitely the Opus context menu that's being used? Does it look the same as in my screenshot, and does the menu item disappear if you turn it off in Preferences?
(BTW, you're absolutely right that the Add single folders as sub-folders of new archives option should be irrelevant in this case.)
If you want, send me a config backup and I'll see if I can reproduce what you're seeing.[/li][/ul]
Haven't seen your next reply yet - so I'll explain the result I mentioned above and why it's a "problem" - for posterity if nothing else , even if you've otherwise understood now after re-reading.
EDIT: weird, I didn't see your "next" reply before I hit submit on this. Sorry...
So the result:
The resulting zip file should contain (and does on a fresh installation on my 'other' / XP system) folder1, folder2, and folder3 as actual folders located directly at the root of the zip file. That's not happening here... only folder2 and folder3 are being copied to the root of the zip file. Instead of folder1 itself also being copied directly into the root of the zip file as should be the case... only it's "contents" are being copied.
If I select the same three folders again, but right click on folder2 in order to call up the context menu this time - then folder1 and folder3 are properly copied into the root of the resulting zip file (folder2.zip), and now it's the "contents" of folder2 that wind up in the root of the zip file. I only mention this to say it's not some "problem" with specific folders... it's always based on the folder which is being right-clicked to call up the context menu that's being mishandled... while the other selected folders are being copied correctly.
Does that more clearly define the problem? I can supply a "correct" and "incorrect" zip file for comparison to clearly illustrate the difference... but is that really necessary ?
As an aside... when archiving MULTIPLE items to the same zip file it's be nice if Opus would default to (and make an option to control) naming the resulting zip file after the current folder name, instead of the name of whichever item was right clicked on (or had the selection rectangle focus or whatever in a button/hotkey scenario). This is what most other archivers I've used do, and makes more sense to me than choosing one of multiple items for the name. This behavior is the main reason I don't use the built-in context menu, and want to use my own raw commands instead. I'll submit an FR...
Absolutely the Opus Context Menu item... mine were cascaded, though I turned that off on last tests
Different than your results for sure... here's my screenshot, starting with the same working folder/file set as you used
I'm stumped about config issues... I completely uninstalled and re-installed and retested before importing my normal config and still have the problem. I'll repeat that and include a fresh re-installed config backup for giggles.
...
, even if you've otherwise understood now after re-reading.