I'm trying to make the complete shift from ZtreeWin, and one function I do often in ZTW is select (recent) files, and zip. However I prefer to create a zip, with its Modified file-date set=latest date in files zipped, and just the 'relative' path stored.
I presume this is done in DOpus by
a) set check-boxes ON
b) tag/select files
c) create zip with command line parameters
the button that does this using external WinZip is:
<?xml version="1.0"?>
<button backcol="none" display="both" textcol="none">
<label>zip WinZipCL</label>
<tip>add to Zip archive with WinZip12 command line </tip>
<icon1>C:\Program Files\WinZip\WINZIP32.EXE,0</icon1>
<function type="normal">
<instruction>"C:\Program Files\WinZip\WZZIP.EXE" -^^ -a -ex -whs -o -p @{allfilepath|filem} {dlgopen|Zip-Archive name|arch.zip} >> wzlog.txt</instruction>
<instruction>@pause</instruction>
</function>
</button>
Note the -o command-line parameter, for zip-date control; Note the -p command-line parameter, for paths relative to Zip-folder vs. files folder(s);
this also works with other external zipping programs (like PKZip etc)
Is there any way to do this all in DOpus10?
A button I figured out that does some of this by using DOpus internal commands is:
<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" textcol="none">
<label>F&iles to specified Zip Archive</label>
<tip>Add the selected files and folders, to a Zip archive in the specified destination folder</tip>
<icon1>#addtozip</icon1>
<function type="normal">
<instruction>Copy ADDTOARCHIVE</instruction>
</function>
</button>
But, then I have to open the Zip in WinZip and 'crunch' the folder tree to get 'relative' paths, and also the zip-file-date is the current date/time (Ugh!).
The default in Opus is to save relative file paths - you would only be getting absolute paths if you had turned on the "Save full file paths" option at the bottom of the Add to Archive dialog.
I can't think of a way to have the file date of the zip file set to that of a file within it, sorry - but I'll add this to the list for consideration for a future version.
Thanks for the response.
Yes, I verified you can store a relative path in the Archive w/DOpus, but its cumbersome:
1)You must be in "Flat" mode (makes sense, like 'global'/branch view in ZTW)
2)select desired files (check-box mode works well, like "tagging" in ZTW); however selection is not permanent - if you navigate to other folder(s) you lose selection (ugh). So you must navigate to the desired parent, before you start selecting.
It sure would be convenient to be able to freely select files by 'check-box', here & there (navigating), then be able to go to "flat" mode, and then do "checkboxes to selection" and have them all be selected, in preparation for zipping.
Or, perhaps there's a way to do: add to previous archive (or default archive path/file-name)?
3) use your "Files to Destination Archive" button, provided on the standard "operations" toolbar,
BUT then you have to answer dialog: "You are copying nested files...recreate directory structure..." press [Recreate].
BUT: now I can't seem to store relative paths using the external program call (I thought I did it once):
\WZZIP.EXE" -a -ex -o -p @{allfilepath|filem} {dlgopen|Zip-Archive name|arch.zip}
Perhaps I don't understand {allfilepath|filem}; how do I get DOpus to include PATH and filename in the file-list?
(having Flat ON or OFF doesn't seem to do it, regardless of what parent directory I'm making the zip-file).
[quote="JohnHP"]Thanks for the response.
Yes, I verified you can store a relative path in the Archive w/DOpus, but its cumbersome:
1)You must be in "Flat" mode (makes sense, like 'global'/branch view in ZTW)
2)select desired files (check-box mode works well, like "tagging" in ZTW); however selection is not permanent - if you navigate to other folder(s) you lose selection (ugh). So you must navigate to the desired parent, before you start selecting.
It sure would be convenient to be able to freely select files by 'check-box', here & there (navigating), then be able to go to "flat" mode, and then do "checkboxes to selection" and have them all be selected, in preparation for zipping.
Or, perhaps there's a way to do: add to previous archive (or default archive path/file-name)?
3) use your "Files to Destination Archive" button, provided on the standard "operations" toolbar,
BUT then you have to answer dialog: "You are copying nested files...recreate directory structure..." press [Recreate].[/quote]
None of this is necessary to store relative paths. As I said, relative paths are always used unless the "Save full file paths" option is on, and it's not on by default.
Maybe I've misunderstood what you mean by relative paths, however. Perhaps you could provide some examples.
OK here is the detail.
I would like to select files (or "checkboxes to selection")
then, create an archive (ZIP) in a parent directory, with just the 'relative' paths from parent down to the folder containing each selected file.
I would like to set the Archive file-created-date to the latest date-time of files included in the zip (NOT the current date-time).
ex list-file with relative paths:
\Renames\tests\Text 01 with more '@garbage chars.txt
\Renames\tests\Text lots of messy 03.txt
I selected these in DOpus as shown:
Then, I used the "Files to destination archive" portion of the DOpus Operations toolbar, to zip the files; note that the Zip is being created in the parent directory
C:\Utl\cd_utl2\FileManagers\DOpus
The resulting zip is attached: zipTst'DOadd_FlatON.zip (1.45 KB)
It does have relative paths, and can be read/extracted; However, note the problem with the zip DOpus has created, when you try to modify it in WinZip15.5:
So, since that didn't work, I tried to create such a zip using the WinZip command-line. The file list that is passed must NOT have the relative paths inlcuded since the resulting zip has NO paths (despite the proper command-line parameter -p). This is verified to work in a CMD window.
I used the button shown in an earlier post zip WinZipCL
DOpus produces a usable Zip, but with NO paths. At one point, I think I was able to get DOpus to create a zip with relative paths, but can't do it again.
HERE is what I'd like to create (done using ZtreeWin, selecting desired, create Zip in parent, with relative paths, with zip-date=newest): zipTst'WZinParent.zip (1.41 KB)
When I uploaded the file, the WinVista file-dates were:
Creation Date: 2001-01-01 9:50:40 am
Last Write: 2001-01-01 9:50:40 am
Last Access: 2001-01-01 9:50:40 am
I don't know if the upload process will alter those dates.
Which represents the latest date of the files archived.
Is there a way I can check the listfile being passed in the command-line, to see how/when it includes pathnames?
Is there another way to set the Archive file-created-date to latest date of included files?
-JP
UPDATE: Weeeelll, now I got DOpus to store 'relative' paths in archive, again (after log-off/log-on & restarting DOpus). Go figure.
So, this DOpus method works pretty well (except for the zipfile-modified/created-date). Guess I can work on trying to find a work-around for that in the meantime.
But, given all the power you've built into DOpus, it seems likely that its not a major code rewrite to include an option to extract the latest date from the selected files, and use that date for the created Archive. That would be a nice feature to have.
-JP
Unfortunately, the Zip created with the (internal) Zip tool, has a non-standard zipping format (it apparently is not zip 2.0 standard). I used "normal" compression which I thought would be compatible. see screen clip:
This makes the zip less useful (you can extract files, but not add or modify it -- except with DOpus, so you're now stuck with a proprietary archive. I would expect that if you used high compression or AES encryption, but not "normal."
Any suggestions???
I don't have WinZip installed but Zip archives created with Opus can be added to fine using both 7-Zip and WinRAR, so I'm not sure what you are seeing there.
Have you turned on Preferences / Zip & Other Archives / Zip Files / Enhanced compression (not compatible with some tools)? Try turning it off, if so, and if Jon's suggestion (above) of turning off zip_large_file_support doesn't help.
Does the archive use filenames which require unicode, or encryption, or files larger than 2GB (either individually or in total)? Those may require Zip modes which WinZip doesn't support.
Also, make sure WinZip is not set to use its "ZipX" compression mode for normal Zip files.
Which version of WinZip are you using?
Does it happen with all archives Opus produces? What about ones made using something else (e.g. 7-Zip or WinRAR)?
It's not something weird, like the ' characters in the name confusing WinZip or anything? (Stranger things have happened...) Or the archive being locked/read-only and WinZip showing the wrong error message?
Ok, the ongoing saga:
I changed "zip_large_file_support"=FALSE (it was TRUE).
note: the option "Enhanced compression" has always been OFF (unchecked).
Created a zip with DOpus button ("Copy ADDTOARCHIVE" command).
Inserted a comment in Zip using DOpus. Zip opens fine, extracts fine in either DOpus and in WinZip15.5.
HOWEVER, any attempt to modify zip with WinZip15.5 (add file, modify comment) still results in error message:
I have sent a "bug report" to WinZip with the relevant information, and a copy of the zip created by DOpus (like the one I uploaded to this bbs) asking them to examine it and let me know why WinZip is complaining.
Archives created with another utility (WinZip) are able to be modified by DOpus (that's nice). Further puzzles: if I create a zip with my legacy PKZip 2.5 (1998), that existing Zip can be modified by DOpus (add comment, add file by drag'n'drop) and then further modified without problems by WinZip15.5!! So it seems that something about initially creating a zip in DOpus using the button ("Copy ADDTOARCHIVE" command) is doing something strange.
Also, in calling a command-line Archiver (such as PKZip or WinZip), the {allfilepath} code passes the entire path; I don't know how to get it to pass a partial/relative path, such as those shown in my earlier post. If I manually create a file-list text file, with the desired partial paths, making a zip with a command-line utility works fine, including saving the zip file-date as latest date from included files. This is what I'm used to doing in ZtreeWin.
So, the current issues are:
DOpus creates ZIP that WinZip claims is not de-facto standard zip v2.0 [although DOpus can modify existing Zip files without problems, it seems]
Passing file-names is either full paths, or no paths (not partial/relative paths)
No way in DOpus to control the zip file-creation/modified date (this can be done with most zip utilities)
So the good news is modifying an existing Zip in DOpus doesn't create any new problems, it seems.
Interesting addendum:
It appears that a zip archive created as "New Archive" in DOpus ("CreateFolder ARCHIVE" command), CAN BE MODIFIED SUCCESSFULLY in WinZip. So, that puts the focus of suspicion on the DOpus button ("Copy ADDTOARCHIVE" command).
-jp
Further: Zips created with NO paths, can be edited by all utilities WITHOUT PROBLEMS;
Once a zip has had paths added (by adding files in "Flat" mode) and "recreate",
problems will occur from that point on, when you try and modify that Zip with WinZip.
I'm a little confused by what you mean by "zips created with NO paths" and "zips with paths added", as well as the distinction between the two ways of creating an archive.
Are you saying that archives created by "Copy ADDTOARCHIVE" never work in WinZip, or only when they have had files added to them in some particular way?
It might be best if you could post some small example working and non-working archives so I can try and see what the differences might be.
Thanks for the response; But, I thought I explained all this in 21 Apr 2012, 18:33 post, above.
The file [zipTst'DOadd_FlatON.zip] already uploaded, is a good example of "relative" paths created in DOpus, and also is a zip that WinZip doesn't like (to modify). Did you examine it?
As I explained in my earlier post 21 Apr 2012, 16:44, "Copy ADDTOARCHIVE" is used by the supplied DOpus button "Archive Files"; when you are in "flat" mode, and answer dialog: "You are copying nested files...recreate directory structure..." press [Recreate], you'll get relative paths (as you said on 21 Apr 2012, 00:03 and again 16:44). BUT such a zip is somehow 'not standard' or at least WinZip doesn't like to modify it as indicated above; WinZip doesn't like the 'zip header' data. Once I "fixed" the 'bad' zip using WinZip, both WinZip and DOpus can modify the zip without problems.
If I create a zip with NO PATHs in DOpus, then add paths/folders in the zip with an other utility (WinZip), then add files with DOpus, WinZip thinks its good -- see the other example I uploaded [zipTst'WZinParent.zip]. So, The key is: creating a Zip with 'partial paths' in DOpus -- always produces a Zip that WinZip doesn't like.
Of course, DOpus can create/modify Zip Archives, but I'm concerned with compatibility for Zips with paths. WinZip tech-support was unhelpful ("just extract and re-zip" which is a simplistic workaround to the issue). Can you ask the DOpus programmer(s) about the code that writes the zip header? Is it different when storing paths? That is what it seems creates the 'bug.'
The WinZip "detailed diagnostics" for both Zips is: zipTst_DiagnosticDetail.zip (6.01 KB)
I got into all this mess because I wanted to be able to create a zip with what DOpus calls 'relative folder/paths'. But attempts to do that in DOpus apparently produce a non-standard Zip; and doing it with a command-line call to PKZip or WinZip, only can do "full" paths or NO paths (not partial/relative paths). So, for now, I'll just keep doing it in ZtreeWin with PKZip2 which works.
-jp
Hi Jon:
Nope, used completely plain settings for making the zips: compression = Normal, Encryption = standard (no pw); split archive UNCHECKED;
I've confirmed: If I "save full file paths" the Zip made by DOpus is fully compatible with WinZip; also with NO file paths is compatible.
The problem only occurs if I am in Flat mode, which prompts the dialog: "You are copying nested files...recreate directory structure..." press [Recreate]. Such a ZIP has partial paths (which I desired), BUT WinZip treats such a zip as "unsupported or invalid zip file structure." So, as stated above, this is where the bug occurs.
Also (perhaps a separate help topic) When Flat mode is ON, with Checkboxes ON, why do I lose check-box selections, when i move to another sub-folder?
I Have set: Options >> Folders >> Folder behavior [ ]OFF "cancel checkbox mode when folder is changed"
Is there some other setting for maintaining checkbox state?
DOpus does so much so well, I was hoping for it to be my do-it-all file manager. Not quite there yet (with these type of zips) I guess.
We're still not sure what you mean by "save full file paths" here.
To us, that means a zip file containing absolute file paths -- that is, including the drive letters themselves. e.g. A file may be stored in the zip as "C:\Windows\Notepad.exe"
Any other path in a zip is just a path. If you copy from Flat View to a zip and elect to recreate the directory structure, all that does it create some folders below the zip file's current location and put the files into those folders. It should be (although perhaps it is not, for some reason) exactly the same as if you manually created folders inside the zip and then copied the files to them normally, outside of Flat View. (It might be worth trying that to see what happens.)
The reason Jon asked about the Split Archive option is that turning it on causes the behaviour you describe in WinZip. It makes sense for split archives to be treated as read-only (it's more work to implement the ability to modify them, and it's rarely needed; 7-Zip is the same). But it seems that if WinZip encounters an archive made in a way which it cannot modify (e.g. because it is a split archive) then it erroneously reports it as being corrupt or off-spec when it is not. (That doesn't mean WinZip is always wrong, but we can see it is wrong in at least one case, so it may be wrong in others as well.)
As for Flat View selections, that is a completely separate topic. There's enough in this thread already. But I'll just say that selections are always remembered per-location. I guess we could implement some inheritance of selection when moving up/down with Flat View on, but nobody has ever asked for it before now.
Well now I'm also unclear on terminology.
The DOpus help file discusses "Save full file paths" and that is the terminology I have used for saving the full sequence of folder names down to the location of the file(s) being zipped. I suppose you could call it "absolute" file paths, but I never saw that in the help file so I haven't used that terminology, but I can if you prefer. I note that the drive letter only represents the drive where the zip is currently located (as shown by the 4 views of the same zip; note the ZtreeWin and the 7zip boxes show the archive copy located on my backup drive (E:); DOpus shows just the path (no letter). All show the 'complete' or "full file path" to the 3 test files, contained in the zip archive.
I'm not sure what you mean by "we can see it [WinZip] is wrong in at least one case".
A Zip archive created with what the help file calls "path is stored relative to the current folder", seems essentially the same as what you describe as "some folders below the zip file's current location" and what the DOpus Help and Jon has called "relative" paths. WinZip behaves consistently differently ("error: unsupported..") for a Zip created with these relative paths.
I think this quirk is a bug, since this archive option is not indicated in the help file as "non-standard"; but now I know about it and can take that behavior into account (knowing it will not necessarily be compatible with other Zip utilities).
I began using 'relative' paths when I had two computers running differnt OS versions: WinXP and laptop running Vista/Win7. My documents were located in:
C:\Documents and Settings{username}\My Documents (WinXP) ...and...
C:\Users{username}\Documents (WinVista)
So, I archived my docs to ZIP with [partial] paths relative to whatever the "documents" folder was on that computer. That way, for an archive located in 'documents'
contents could be unzipped and land in the proper folder underneath/below 'documents' independent of the OS version.
[ex: file "C:\Users{username}\Documents\sws\GEG\Geg9\Labs\Lab06b_Glacial Landscape.DOC"
unzips the DOC into: "\sws\GEG\Geg9\Labs"]
Do you have a better idea how to do this in DOpus? It seems the 'relative' paths is the way, based on the help file.
I'm not sure why this seems so hard to explain. I'm not sure why it seems strange to you; it seems this would be a situation that's quite common as a way of coping with Microsoft's tendency to "improve" things, or other differences in directory structure. Since DOpus is a file manager, I would think this is a useful feature in managing files & their archives, and doing it in DOPus could be done in a standard, not proprietary, way.
[quote]If this option is turned on then the full paths of files you add to the archive will be stored in the archive. If this option is off the path is stored relative to the current folder.
For example, say you go into C:\Test, select a folder called Reports that contains one file (Sales.docx) and add it to an archive. If this option was off, the path of Sales.docx in the archive would be stored as Reports\Sales.docx. If the Save full file paths option was on, the path stored would be C:\Test\Reports\Sales.docx.[/quote]
You want that option to be OFF, but you have it on right now.
It looks like WinZip cannot modify archives that have full paths stored in them, and WinZip then says the archive is "unsupported or invalid" if you try to do so. The error message is vague and, in this case, this archive is not invalid but WinZip does not support modification of it. As with a split archive, the archive is storing information in a way which is allowed by the zip specification and which WinZip is happy to read but which WinZip decides not to allow you to modify.
Turning off the full paths option does not prevent relative paths being stored in the zip. In fact, it enables relative paths to be stored. You want the option off, not on.
In summary, WinZip's error message is vague and you want to turn the Zip Options: Save full file paths off.
[Edit: Clarified what I meant about WinZip's error message, after seeing what it said in your screenshot. WinZip is not saying the archive is invalid. It is saying it is "unsupported or invalid," which is different.]
