Can't Untar a Complete Directory Using Tar -Cvpzf

can't untar a complete directory using tar -cvpzf

Your tar can't find gzip. If you don't have gzip, you can't make a .gz file. You should look for a gzip executable on your system. What kind of system is it?

In the meantime, you could leave off the "z" and just transfer a .tar file. It will be bigger, but at least you'll be able to move your data to the other server.

Shell command to tar directory excluding certain files/folders

You can have multiple exclude options for tar so

$ tar --exclude='./folder' --exclude='./upload/folder2' -zcvf /backup/filename.tgz .

etc will work. Make sure to put --exclude before the source and destination items.

Script don't extract tar

You've changed PATH to /usr/src so when tar tries to exec gzip, it cannot find it because it only looks in /usr/src. You'll need to add the location of gzip to PATH (and the location of every tool that the configure script is going to call, as well as make), or call it explicitly instead of letting tar call it, or (best choice), don't modify PATH. If you insist on changing PATH, try PATH=/usr/src:/usr/sbin:/usr/bin:/sbin:/bin or PATH=/usr/src:$PATH, but really it's best to leave it alone and really odd to put a directory named src into it.

archiving hidden directories with tar

The answer is that the * wildcard is handled by the shell and it just does not expand to things that start with a dot. The other wildcard ? also does not expand to things that start with a dot. Thanks to Keith for pointing out it is the shell that does the expansion and so it has nothing to do with tar.

If you use shopt -s dotglob then expansion will include things like .filename. Thanks to Andy.

Use shopt -u dotglob to turn it off.

Switching the dotglob option does not change ls itself. Rather it just changes expansion behaviour as exhibited in something like ls *.

Edit: My recommendations are in a comment below.

After tar extract, Changing Permissions

If you want to keep the permissions on files then you have to add the -p (or --preserve-permissions or --same-permissions) switch when extracting the tarball. From the tar man pages :

--preserve-permissions
--same-permissions
-p
    When `tar' is extracting an archive, it normally subtracts the
    users' umask from the permissions specified in the archive and
    uses that number as the permissions to create the destination
    file.  Specifying this option instructs `tar' that it should use
    the permissions directly from the archive.

So PHP code should be :

exec("tar -xzfp foo.tar.gz");

Linux: Stopping tar command?

ps -ef | grep tar

Figure out the tar command's PID, then kill it with.

kill <pid>

For instance, kill 1234 if it is PID 1234. Wait a bit, and if it hasn't died gracefully from that then hit it with the sledgehammer.

kill -9 <pid>

Alternatively, you could kill all running tar commands with a single command.

pkill tar

# if necessary
pkill -9 tar

Either way, once the process dies, the disk space will clear up. Deleting the file didn't help because a running process still has the file open. Files aren't truly deleted until they're removed and they're not open in any process.

How can I replace my home directory without coorupting my system?

That's quite doubtful approach to archiving the data. First of all, as you mentioned, windows will remove the permission bits. Running chmod -R 755 afterwards has very bad consequences because some programs in order to work require very specific access bits on some files (ssh keys for example). Not to mention that making everything executable is bad for security.

Considering your scenario, you may either
a) backup everything into Tar or Zip archives - this way permissions will be intact
b) Make virtual disk file which will be stored on shared windows drive and mounted to /home/pi

How to do scenario A:

cd /home/pi
tar cvpzf backup.tar.gz .

Copy backup.tar.gz to shared drive

to unpack:

cd /home/pi
tar xpvzf backup.tar.gz

Pros:

• One-line backup
• Takes small amount of space

Cons:

• Packing/unpacking takes time

How to do scenario B:

1) Create a new file to hold the virtual drive volume:

cd /mnt/YourNetworkDriveMountPoint
fallocate -l 500M HomePi.img
dd if=/dev/zero of=HomePi.img bs=1M count=500
mkfs -t ext3 HomePi.img

2) Mount it to home dir

mount -t auto -o loop HomePi.img /home/pi/

500 means the disk will be 500 megabytes in size
This way your whole pi will be saved as a file on windows shared drive, but all the content will be in ext3 so all permissions are preserved.
I suggest you though to keep the current version image file on Pi device itself and the old versions on shared drive. Just copy files over if you need to switch because otherwise if all images are on shared drive then read/write performance will be 100% dependant on network speed.

You can then easily make copies of this file and swap them instantly by unmounting existing image and mounting new one

Pros:

• Easy swap between backup versions
• Completely transparent process

Cons:

• If current image file is on shared drive, performance will be reduced
• It will consume considerably more space because all 500 megs will be preallocated.
• Pi user must be logged off during image swap for obvious reasons

Now, as for issues with Desktop not displayed, you need to check /var/log/Xorg.0.log for detailed messages. Likely this is caused by messed permissions. I would try to rename/remove your current Xorg settings and cache which are located somewhere in /home/Pi/.config/ (depends on what you're using - XFCE, Gnome, etc.) and let X server recreate them. But again, before doing this please check Xorg.0.log for exact messages - maybe there's another error. If you need any further help please comment to this answer

---

Related Topics