This useful answer shows how one can copy the given files to the clipboard. Is it possible in a similar way to copy files from a zip archive, as Explorer does? One can unzip the archive to a temporary folder and copy from there, but then there is a problem of subsequent deletion of the files, since it is not known when they can be deleted (the program may already be closed at this time).
Related
I have several Zip folders (produced by Google Takeout service) and I want to merge them since Google provides many small Zips as an output. For the sake of merging I've chosen to use ditto command on Mac, which will merge all files/folders including the metadata.
Now, the problem I have is this: ditto command creates another copy of the source zip file and places it into destination folder. I would like this source zip file to be deleted after extraction and have no copy of the zip added to the destination folder due to the limited size of the HDD. Each of 35 Zip files weights about 50Gb. Any ideas how I should alter my command?
So far my intended line of command would be:
ditto -x -k -V *.zip result 1>log.txt 2>&1
I am zipping a folder through an antrun command with 7zip and while the command is running, there are some temporary *profile.gz files that are deleted, this causes the 7zip to show a series of warnings that it cannot find the deleted files. Is it a switch to ignore the missing files? I assume that before starting the compression, 7z collects a list of files that need to be archived.
I wanted to know how to move files to a .zip archive. I'm using this code: xcopy C:\Folder C:\AnotherFolder\zippedFolder.zip. This copies the files from C:\Folder DIRECTLY into the archive, but I want to have that file in the archive (so i can doubleclick the archive and see the file unopened).
Want to do this to create an excel file with a .cmd
Use -m to import a file to a ZIP archive.
I found this on StackOverflow maybe it helps you.
How to move a file in to zip uncompressed, with zip cmd tool
But be careful it deletes the source file after it adds it to the archive. See the link for more details.
UPDATE
Instructions from this site. http://linux.about.com/od/commands/l/blcmdl1_zip.htm.
-m moves the specified files into the ZIP archive; actually, this deletes the target directories/files after making the specified ZIP archive.
If a directory becomes empty after removal of the files, the directory is also removed. No deletions are done until zip has created the archive without errors. This is useful for conserving disk space, but is potentially dangerous so it is recommended to use it in combination with -T to test the archive before removing all input files.
zip -m yourfile zip.file
Compressing a folder into a .zip file is a common way to treat a folder as file, for example, uploading a folder. Is there a faster way to "pack" the contents of a folder into a file (without taking the time to compress)?
You should use a tarfile. In unix or mac, its the tar command. On Windows there is a tool called 7-zip.
You can see more details here.
I am trying to use grsync (A GUI for rsync) for Windows to run backups. In the directory that I am backing up there are many larger files that are updated periodically. I would like to be able to sync just the changes to those files and not the entire file each backup. I was under the impression that rsync is a block-level file copier and would only copy the bytes that had changed between each sync. Perhaps this is not the case, or I have misunderstood what block-level file coping is!
To test this I used grsync to synchronize a 5GB zip file between two directories. Then I added a very small text file to the zip file and ran grsync again. However it proceeded to copy over the entire zip file again. Is there a utility that would only copy over the changes to this zip file and not the entire file again? Or is there a command within grsync that could be used to this effect?
The reason the entire file was copied is simply that the algorithm that handles block-level changes is disabled when copying between two directories on a local filesystem.
This would have worked, because the file is being copied (or updated) to a remote system:
rsync -av big_file.zip remote_host:
This will not use the "delta" algorithm and the entire file will be copied:
rsync -av big_file.zip D:\target\folder\
Some notes
Even if the target is a network share, rsync will treat it as path of your local filesystem and will disable the "delta" (block changes) algorithm.
Adding data to the beginning or middle of a data file will not upset the algorithm that handles the block-level changes.
Rationale
The delta algorithm is disabled when copying between two local targets because it needs to read both the source and the destination file completely in order to determine which blocks need changing. The rationale is that the time taken to read the target file is much the same as just writing to it, and so there's no point reading it first.
Workaround
If you know for definite that reading from your target filesystem is significantly faster than writing to it you can force the block-level algorithm to run by including the --no-whole-file flag.
If you add a file to a zip the entire zip file can change if the file was added as the first file in the archive. The entire archive will shift. so yours is not a valid test.
I was just looking for this myself, I think you have to use
rsync -av --inplace
for this to work.