Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Zip /U /R file not updated?

vefatica

vefatica

May
13,399
190
First ZIP: The file didn't exist; it was created.

Then I added a file to the folder being zipped and edited a file that was already there.

Second ZIP: Nothing was added to, or updated in, the zip-file.

Code: 
v:\> zip /u /r dt:\Projects.zip /[!*.vc.db] d:\Projects2022
<= D:\Projects2022\*

v:\> zip /u /r dt:\Projects.zip /[!*.vc.db] d:\Projects2022

v:\>
 
Alpengreis said:
Typo in drive name "dt:"?
Click to expand...
No, that's a directory alias for my desktop folder. I used ProcessMonitor to watch TCC's file system activity during the second one. It did a lot of reading the zipfile (looking for file times?) but no writing to the zipfile. And it did not access the target folder at all.
 
Hmm ... here that works with exactly same syntax.

I would ask you if the created ZIP was created with another ZIP program so it could be not a valid ZIP (there exists differents standards which are not compatible among themselves) BUT since you said it dit not even access the target folder that makes no sense ...

That's a VERY weird thing ...

Could it be that the ZIP command has a problem with aliases (not tested (yet))? Tested now, seems not the problem.
Could it be that your desktop folder is "protected" somehow (ransomware protecting software or similar)?

Else I am out of ideas currently ...
 
Last edited:
Did you do it as I did? First give the ZIP command when the zipfile does not exist, than add a file to the target directory, then give the ZIP command again?
 
Yes, I think so (at least VERY similar):

I made the following:

0) There was no ZIP.
1) I gave "your" command, a ZIP was created in the target dir then with some files.
2) I edited a file in the this newly created ZIP in the target dir.
3) I gave again "your" command. The before edited ZIP was updated after (in target dir).

And same steps also tried with a single file only ...
 
Here's a simple test. Please try it.

Code: 
v:\> del ziptest.zip
Deleting V:\ziptest.zip
     1 file deleted

v:\> md ziptest

v:\> touch /c ziptest\doc1
2024-04-08 16:54:02.782  V:\ziptest\doc1

v:\> zip /r /u ziptest.zip ziptest
<= V:\ziptest\*

v:\> zip /v ziptest.zip
2024-04-08  20:54              1  100%  ziptest\
2024-04-08  20:54              1 -100%  ziptest\doc1

v:\> touch /c ziptest\doc2
2024-04-08 16:54:30.664  V:\ziptest\doc2

v:\> zip /r /u ziptest.zip ziptest

v:\> zip /v ziptest.zip
2024-04-08  20:54              1  100%  ziptest\
2024-04-08  20:54              1 -100%  ziptest\doc1
 
Sure.

Here is the result (it works here):

Code: 
ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:35 | $ del ziptest.zip
Lösche D:\ziptest.zip
     1 Datei gelöscht

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:35 | $ md ziptest

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:35 | $ touch /c ziptest\doc1
08.04.2024 23:35:55.328  D:\ziptest\doc1

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:35 | $ zip /r /u ziptest.zip ziptest
<= D:\ziptest\*

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:36 | $ zip /v ziptest.zip
2024-04-08  21:35              1  100%  ziptest\
2024-04-08  21:35              1 -100%  ziptest\doc1

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:36 | $ touch /c ziptest\doc2
08.04.2024 23:36:15.537  D:\ziptest\doc2

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:36 | $ zip /r /u ziptest.zip ziptest
<= D:\ziptest

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:36 | $ zip /v ziptest.zip
2024-04-08  21:36              1  100%  ziptest\
2024-04-08  21:35              1 -100%  ziptest\doc1
2024-04-08  21:36              1 -100%  ziptest\doc2

ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:36 | $
 
And you use also the v32 with internal zip command (no alias for "zip")?

Here: TCC 32.00.15 x64 Windows 10 [Version 10.0.19045.4239]

Code: 
ag-usr@LAPTOP-C760CBHO >["d:\"]
ADM: N | Zeit: 23:45 | $ which zip
zip ist ein interner Befehl

In your case it almost looks like something is blocking the ZIP (holds open) and you just can't process more into the same ZIP asynchronously. Have you checked, if the ZIP files is still open after 1st ZIP command?
 
Thanks for trying. Yes, I'm using the internal ZIP in v32. I checked with handle64.exe (Sysinternals), there are no open handles.
 
Your welcome, no problem.

That's really a mystic thing!

BTW: "ZIP /U /R" does also update files here wich are NEWER then files on disk. That's also not correct IMHO. Will make another threade for that.
 
ZIP /R does not support /U unless you provide filenames. The ZIP library does not support it, and it would require a lot of new code to replace the library interpretation of a subdirevctory zip with one that did a dual scan of the ZIP file and the specified directory and did a match of the filenames & test them for /U or /F.

By itself, /R always replaces all the files in the .zip file with the ones in the specified directory (and subdirectories). It's behaved this way for many years, and no one has ever submitted a suggestion that it be changed.
 
I wish ZIP would leave <= D:\Projects2022 (or something) on the screen so I can tell it did something.
 
Can ZIP /R exclude certain files? I want to zip my projects directory and exclude *.vc.db, *.pch, and *.ipch. That would make a zip file of 250MB (vs. 2GB).
 
Already done. Here's the one I'm using. "-uq0" means remove from the archive anything that doesn't exist on-disk.

Code: 
d:\7zip\7z.exe u -uq0 -xr!*.vc.db -xr!*.ipch -xr!*.pch t:\projects.zip d:\Projects2022\
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate