pack files on windows and preserve folder timestamps - windows

I want to put a big folder on Windows box into one archive (tar, zip, gzip, whatever). Is there a tool that can preserver all folder timestamps?
The timestamps have to be preserverd after unpacking the archive on a Linux box.
Any ideas are welcome!

tar will do fine. gzip is for single file compression, zip won't preserve directory timestamps.
EDIT: Sample.
tar jcpf backup.tbz2 thedir
rm -rf thedir
tar jxpf backup.tbz2
Timestamps preserved.
EDIT2:
cygwin tar correctly preserves timestamps. Tested with tar jcf on cygwin, tar jxf on linux.
EDIT3:
WinRar preserves directory timestamps, linux unrar restores them properly.

DotNetZip preserves timestamps on folders, as well as files.

It seams that there's no soluation to all my requirements:
Pack on Windows an preserve folder timestamps
Unpack on Linux and preserve original folder timestamps
I prefer a copy/paste aka portable installation of the tool, otherwise the deployment gets to complicated.
A partial, drop in cygwin installation by just copying the necessary exe and dll files works, but doesn't preserve the folder timestamps.
Full cygwin installation is not easily possible since the windows client machines are on terminal server (see http://www.cygwin.com/faq/faq.setup.html#faq.setup.setup-fails-on-ts)
Zip doesn't work because unzip on ubuntu cannot preserver folder timestamps, even if the zip tool of choice does.

Related

How to zip a folder in MacOS without creating an extra directory inside the zip file

I got a .zip file from my friend and it was compressed under windows, which contains three subfolders inside of it, and when I check the contents of it on my Mac terminal it looks like this:
Now I unzip this file and then zip it through terminal, and when I check the contents of that zip file it becomes like this:
I have googled how to zip on mac without creating a subfolder with same name but none of them solves the problem, my question is how to do the zip on Mac which makes the zip file looks exactly same with the initial one I got.
Thanks very very much
New edit:
I think I might did not do very well to summarize my problem, so the initial folder contains three sub-folders and all of them were created in windows environment and compressed on windows, when I tried to unzip it on my MacOS machine, the unzipped folder looks still good but when I do the compression on Mac and then view the .zip file through unzip -l xxxx.zip, it is giving me 6 files in which the three sub-folders are also treated as files. Based on my knowledge this is because in BSD systems all the folders are treated as files but in windows they are not, what I'm currently doing is to delete all these files that represent folders through "zip -d", which I know is very silly. I would be more than happy to talk about this from an operating system view with anybody who is interested in it. Thanks in advance.
For me this command works fine:
zip -j zippedFolder.zip myFolder/*
To unzip I used
unzip zippedFolder.zip
and I've got only the data from the folder.
Example: The folder I want to zip is on the desktop and he's called testFolder.
Open Terminal
cd /Users/yourUser/Desktop
zip -f myZip.zip testFolder/*

Copy large amount of files from MAC to Windows server and preserve modify and creation date

I have an issue with moving a large number of files and folders from old MAS OSX server ( 10.9.4) to Windows Server 2016.
I already try to use robocopy but I always get an error - File creation error - The file or directory is not a reparse point.
The same thing happens when I am using xcopy.
I also tried to copy files from MAC to windows after mounting a share on MAC and use scp but also there are some errors and not all files are moved.
Can anyone know a way how I can copy files and preserver this creation and modified date?
rsync works fine now but I needed to give full permission over the newtork to prevent any issues
I generally use tar.
tar like rsync and lsyncdpreserves modification times, etc.
For tar you would:
tar up all the files just like a backup
gzip the tar ball
copy the gzipped tar ball to Windows
Extract the files using WinRAR. The file modification times will be preserved.

Why are there duplicate files when extracting tar.gz archive

I have a strange problem with tar.gz archives that I do not understand.
I create the archive on a linux server with tar -czf
When I extract them on a windows machine using 7z x, I always get notifications that some (not all) files already exist. (They are extracted to an empty directory.)
The files it wants to replace have todays date, the ones already there have the original (modified on) date they had on the server.
Since I want to preserve the original timestamps I can use the -aos option for 7z, but I would like to understand why this is happening and make sure that I have an identical mirror of the files on the server after unpacking locally.
:D The problem is a derelict duplicate directory that exists both as uppercase and lowercase on the Linux server - which of course can only be one directory when extracted on the Windows System ( \Mydir\ and \mydir\ ) problem solved. :)
Thanks for the help!

Untar multipart tarball on Windows

I have a series of files named filename.part0.tar, filename.part1.tar, … filename.part8.tar.
I guess tar can create multiple volumes when archiving, but I can't seem to find a way to unarchive them on Windows. I've tried to untar them using 7zip (GUI & commandline), WinRAR, tar114 (which doesn't run on 64-bit Windows), WinZip, and ZenTar (a little utility I found).
All programs run through the part0 file, extracting 3 rar files, then quit reporting an error. None of the other part files are recognized as .tar, .rar, .zip, or .gz.
I've tried concatenating them using the DOS copy command, but that doesn't work, possibly because part0 thru part6 and part8 are each 100Mb, while part7 is 53Mb and therefore likely the last part. I've tried several different logical orders for the files in concatenation, but no joy.
Other than installing Linux, finding a live distro, or tracking down the guy who left these files for me, how can I untar these files?
Install 7-zip. Right click on the first tar. In the context menu, go to "7zip -> Extract Here".
Works like a charm, no command-line kung-fu needed:)
EDIT:
I only now noticed that you mention already having tried 7zip. It might have balked if you tried to "open" the tar by going "open with" -> 7zip - Their command-line for opening files is a little unorthodox, so you have to associate via 7zip instead of via the file association system built-in to windows. If you try the right click -> "7-zip" -> "extract here", though, that should work- I tested the solution myself (albeit on a 32-bit Windows box- Don't have a 64 available)
1) download gzip http://www.gzip.org/ for windows and unpack it
2) gzip -c filename.part0.tar > foo.gz
gzip -c filename.part1.tar >> foo.gz
...
gzip -c filename.part8.tar >> foo.gz
3) unpack foo.gz
worked for me
As above, I had the same issue and ran into this old thread. For me it was a severe case of RTFM when installing a Siebel VM . These instructions were straight from the manual:
cat \
OVM_EL5U3_X86_ORACLE11G_SIEBEL811ENU_SIA21111_PVM.tgz.1of3 \
OVM_EL5U3_X86_ORACLE11G_SIEBEL811ENU_SIA21111_PVM.tgz.2of3 \
OVM_EL5U3_X86_ORACLE11G_SIEBEL811ENU_SIA21111_PVM.tgz.3of3 \
| tar xzf –
Worked for me!
The tar -M switch should it for you on windows (I'm using tar.exe).
tar --help says:
-M, --multi-volume create/list/extract multi-volume archive
I found this thread because I had the same problem with these files. Yes, the same exact files you have. Here's the correct order: 042358617 (i.e. start with part0, then part4, etc.)
Concatenate in that order and you'll get a tarball you can unarchive. (I'm not on Windows, so I can't advise on what app to use.) Note that of the 19 items contained therein, 3 are zip files that some unarchive utilities will report as being corrupted. Other apps will allow you to extract 99% of their contents. Again, I'm not on Windows, so you'll have to experiment for yourself.
Enjoy! ;)
This works well for me with multivolume tar archives (numbered .tar.1, .tar.2 and so on) and even allows to --list or --get specific folders or files in them:
#!/bin/bash
TAR=/usr/bin/tar
ARCHIVE=bkup-01Jun
RPATH=home/user
RDEST=restore/
EXCLUDE=.*
mkdir -p $RDEST
$TAR vf $ARCHIVE.tar.1 -F 'echo '$ARCHIVE'.tar.${TAR_VOLUME} >&${TAR_FD}' -C $RDEST --get $RPATH --exclude "$EXCLUDE"
Copy to a script file, then just change the parameters:
TAR=location of tar binary
ARCHIVE=Archive base name (without .tar.multivolumenumber)
RPATH=path to restore (leave empty for full restore)
RDEST=restore destination folder (relative or absolute path)
EXCLUDE=files to exclude (with pattern matching)
Interesting thing for me is you really DON'T use the -M option, as this would only ask you questions (insert next volume etc.)
Hello perhaps would help.
I had the same problems ...
a save on my web site made automaticaly in Centos at 4 am create multiple file in multivolume tar format (saveblabla.tar, saveblabla.tar1.tar, saveblabla.tar2.tar,etc..)
after downloading this file on my PC (windows) i can't extract them with both windows cmd or 7zip (unknow error).
I thirst binary copy file to reassemble tar files. (above in that thread)
copy /b file1+file2+file3 destination
after that, 7zip worked !!! Thanks for you help

What are these stray zero-byte files extracted from tarball? (OSX)

I'm extracting a folder from a tarball, and I see these zero-byte files showing up in the result (where they are not in the source.) Setup (all on OS X):
On machine one, I have a directory /My/Stuff/Goes/Here/ containing several hundred files.
I build it like this
tar -cZf mystuff.tgz /My/Stuff/Goes/Here/
On machine two, I scp the tgz file to my local directory, then unpack it.
tar -xZf mystuff.tgz
It creates ~scott/My/Stuff/Goes/, but then under Goes, I see two files:
Here/ - a directory,
Here.bGd - a zero byte file.
The "Here.bGd" zero-byte file has a random 3-character suffix, mixed upper and lower-case characters. It has the same name as the lowest-level directory mentioned in the tar-creation command. It only appears at the lowest level directory named. Anybody know where these come from, and how I can adjust my tar creation to get rid of them?
Update: I checked the table of contents on the files using tar tZvf: toc does not list the zero-byte files, so I'm leaning toward the suggestion that the uncompress machine is at fault. OS X is version 10.5.5 on the unzip machine (not sure how to check the filesystem type). Tar is GNU tar 1.15.1, and it came with the machine.
You can get a table of contents from the tarball by doing
tar tZvf mystuff.tgz
If those zero-byte files are listed in the table of contents, then the problem is on the computer making the tarball. If they aren't listed, then the problem is on the computer decompressing the tarball.
I can't replicate this on my 10.5.5 system.
So, for each system:
what version of OSX are you using?
what filesystem is in use?
I have not seen this particular problem before with tar. However, there is another problem where tar bundles metadata files with regular files (they have the same name but are prefixed with "._"). The solution to this was to set the environment variable COPYFILE_DISABLE=y. If those weird files you have are more metadata files, maybe this would solve your problem as well?
Failing that, you could try installing a different version of tar.
On my MacOS X (10.4.11) machine, I sometimes acquire files .DS_Store in a directory (but these are not empty files), and I've seen other hidden file names on memory sticks that have been used on the Mac. These are somehow related to the Mac file system. I'd guess that what you are seeing are related to one or the other of these sets of files. Original Macs (MacOS 9 and earlier) had data forks and resource forks for files.
A little bit of play shows that a directory in which I've never used Finder has no .DS_Store file; if I use the Finder to navigate to that directory, the .DS_Store file appears. It presumably contains information about how the files should appear in the Finder display (so if you move files around, they stay where you put them).
This doesn't directly answer your question; I hope it gives some pointers.
I don't know (and boy is this a hard problem to Google for!), but here's a troubleshooting step: try tar without Z. That will determine whether compress or tar is causing the issue.

Resources