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!
Related
I downloaded a big folder in Google Drive that was split into 5 parts:
Myfolder-20200911T192019Z-001.zip
Myfolder-20200911T192019Z-002.zip
Myfolder-20200911T192019Z-003.zip
Myfolder-20200911T192019Z-004.zip
Myfolder-20200911T192019Z-005.zip
I'm having some trouble to extract it into the single folder it originally is. Is there a straighforward way to unzip all of them together and recreate the original folder? Maybe some specific command in gzip? I didn't wish to install any program just to perform this task.
The above answer didn't work for me.
The files needed to be unzipped sequentially rather than just concatenated together.
For anyone coming here from a general search about combining zip files but specifically to combine multipart zips from Google Drive, I found this answer to be the one that worked:
https://superuser.com/questions/1255221/how-to-unzip-multiple-zip-files-into-a-single-directory-structure-e-g-google-d
i.e. for the above (creating an output directory to start with if necessary):
mkdir outputFolder
unzip "Myfolder-20200911T192019Z-00*" -d outputFolder
You can do cat Myfolder-20200911T192019Z* > total.zip to combine your zip files and then run unzip total.zip
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/*
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.
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.
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.