[TC 4.2.1] Filetool.sh changes owner of folders when backup

[AmatCoder]

When I write in .filetool.lst (for example) :

Code: [Select]

home/tc/.gconf/apps/me-tv
filetool.sh changes gconf and apps owner to root  when previously it was tc. It makes that applications that use .gconf folder complain about it.

With :

Code: [Select]

home/tc/.gconf works fine.

It seems that filetool.sh only honor the owner of the last folder in the path.

[gerald_clark]

Lines in .filetool.lst cannot start with a "/".

[Rich]

Hi AmatCoder
Lines in  .filetool.lst  should not begin with a  /  because all paths are relative to the root.
If you do that they get translated to  //pathname/name

[AmatCoder]

No, I was writing from memory. There are not "/" in my lines.

I edit my first post. Thanks to both for reply.

[curaga]

It is directly passed to tar; please test if GNU tar behaves the same. If so, it's tar behavior, if not, it might be a bug in busybox tar.

[roberts]

I am assuming that this claim is made as a result of loading.using me-tv.tcz.
Testing this extension with backup and restore did not result in such claim. Each ld before and after on .gconf,  .gconf/apps,  and .gconf/apps/me-tv remained tc.staff.

I find it interesting that specific directory was added to .filetool.lst when by default home in its entirety is in the backup. Nevertheless even adding specific directory did not produce such claim.

Even when forcing the last directory "me-tv" to root.root backup and restore did not produce such claim on .gconf or .gconf/apps.

Providing more details that can reproduce this claim would be helpful including file system that is being restored and ls -ld on each directory before and after.

[AmatCoder]

It is directly passed to tar; please test if GNU tar behaves the same. If so, it's tar behavior, if not, it might be a bug in busybox tar.

Yes, it also happens with GNU Tar.

I am assuming that this claim is made as a result of loading.using me-tv.tcz.
Testing this extension with backup and restore did not result in such claim. Each ld before and after on .gconf,  .gconf/apps,  and .gconf/apps/me-tv remained tc.staff.

No, me-tv folder is just an example...Here it happens always... You can do:

Code: [Select]

install -d /home/tc/folder/folder2
folder  and folder2 have tc:staff ownership

Edit .filetool.lst and add:

Code: [Select]

home/tc/folder/folder2
Then you go Control Panel->Backup/Restore and backup.
Delete folder
Go Control Panel->Backup/Restore and restore.
You can see folder now has root:staff ownership. folder2  preserves tc:staff

I find it interesting that specific directory was added to .filetool.lst when by default home in its entirety is in the backup. Nevertheless even adding specific directory did not produce such claim.

Well, here not...I prefer to put individual items in .filetool.lst so I take away whole home from it.

Providing more details that can reproduce this claim would be helpful including file system that is being restored and ls -ld on each directory before and after.

My mydata.tgz is stored in a FAT32 file system.

[AmatCoder]

I have written a (dirty) bash script to show issue...

WARNING: Do not use without backing up your mydata.tgz

Code: [Select]

#!/bin/sh

#Create folders
#
install -d /home/tc/first-folder/second-folder

# Show folder properties
#
cd /home/tc/first-folder
echo "BEFORE:"
ls -ld
cd ..

# Backup .filetool.lst
#
mv -f /opt/.filetool.lst /opt/filetoolbk.lst
rm -f -r /opt/.filetool.lst

#Create a new .filetool.lst with two items: 'opt' and 'home/tc/first-folder/second-folder'
#
cd /opt
echo "opt" > .filetool.lst
echo "home/tc/first-folder/second-folder" > .filetool.lst

#Run filetool.sh for backup
#
filetool.sh -b >/dev/null

#Delete folder (to simulate a reboot)
#
rm -f -r /home/tc/first-folder

#Run filetool.sh for restore
#
filetool.sh -r >/dev/null

# Show folder properties
#
cd /home/tc/first-folder
echo "AFTER:"
ls -ld

#Delete folder (now we need sudo), restore old .filetool.lst and backup again...
#
cd
sudo rm -f -r /home/tc/first-folder
mv -f /opt/filetoolbk.lst /opt/.filetool.lst
filetool.sh -b >/dev/null
You can see output as:

Code: [Select]

BEFORE:
drwxr-sr-x    3 tc        staff        60 Jan 17 17:56
AFTER:
drwxr-sr-x    3 root      staff        60 Jan 17 17:56

[curaga]

I can confirm, and that GNU tar behaves the same. Since this is tar behavior across all versions, I'm not sure what should be done.

[AmatCoder]

I have managed to override this behavior (or bug, I am not sure...) with one of two:

a) Do not use sudo when extracting files.
or
b) Use '-P' option instead '-C / ' when compressing files.

(lines 234 and 238 in filetool.sh)

This seem to work but I am not sure if it could cause some problem. 

More: Issue happens only when tar uses -T option...If I pass folders directly to command-line then it works fine (even with 'sudo' and '-C / '). Edit: Forget about it...Although GNU Tar has some options to manage directories properties, they are not avaliable with Busybox Tar.

I am using a workaround. I added to .profile:

Code: [Select]

sudo chown -R tc:staff /home/tc
This changes all directories (files are left untouched) below /home/tc  to tc:staff