Gnome-Mplayer Fails to Save Changes

[SamK]

TC v4.7.3
Gnome-Mplayer v 1.0.6

Changes made using the interface in Edit-->Preferences-->tabs are not saved.  Closing and re-opening the app reverts to the pre-change state.  A settings directory is not present in ~/.config.

[AmatCoder]

It's working here... Are you sure you're using tcz version?

[SamK]

It's working here... Are you sure you're using tcz version?

Yes.  It was downloaded and installed via the Apps tool.  Apps also reports no issues with missing dependencies and also reports md5sum as OK.

Additional Info

Code: [Select]

ls /mnt/sdb1/tce/optional/gno*
/mnt/sdb1/tce/optional/gnome-mplayer.tcz
/mnt/sdb1/tce/optional/gnome-mplayer.tcz.dep
/mnt/sdb1/tce/optional/gnome-mplayer.tcz.md5.txt

Code: [Select]

cat /mnt/sdb1/tce/optional/gnome-mplayer.tcz.md5.txt
26b0f90f39e86b1b4d47a9a37cfb5414  gnome-mplayer.tcz

Code: [Select]

cat /mnt/sdb1/tce/onboot.lst
Xorg-7.6.tcz
Xprogs.tcz
libfltk-xft.tcz
kmaps.tcz
iptables.tcz
icewm.tcz
OSS.tcz
xmms.tcz
xmms-flac.tcz
xmms-mp4.tcz
xmms-wma.tcz
gnome-mplayer.tcz
links.tcz
e3.tcz
xf86-video-ati.tcz
xf86-video-mach64.tcz

Code: [Select]

ls ~/.config
xfe/

[AmatCoder]

Preferences storage is made by libgmtk.

Ensure your version is:

Code: [Select]

tc@box:~$ cat /mnt/sdb1/tce/optional/libgmtk.tcz.md5.txt
c53cf1cdb7cf6bb8293e83c82cbd9bd2  libgmtk.tcz


[SamK]

I found the cause of the problem.  It is not a bug but a user error.  The ownership of .config had been changed to root:staff, preventing the creation configuration files.  I don't know when or why I did this.

Apologies for an incorrect report, and thanks for a swift reply.

[AmatCoder]

The ownership of .config had been changed to root:staff, preventing the creation configuration files.  I don't know when or why I did this.

This bug happens to me... See: http://forum.tinycorelinux.net/index.php/topic,12361.0.html

Summarizing: if you put into .filetool.lst something like:

Code: [Select]

home/tc/.config/gnome-mplayer
when reboot /gnome-mplayer/ folder keeps owners but /.config/ folder changes to root:staff 
Check it.

Apologies for an incorrect report, and thanks for a swift reply.

No problem... 

[SamK]

This bug happens to me... See: http://forum.tinycorelinux.net/index.php/topic,12361.0.html

Summarizing: if you put into .filetool.lst something like:

Code: [Select]

home/tc/.config/gnome-mplayer
when reboot /gnome-mplayer/ folder keeps owners but /.config/ folder changes to root:staff 
Check it.

Thanks for the link.  It accurately describes the symptoms seen here.

While it is pleasing to know there is not a bug in gnome-mplayer, and gratifying to learn the behaviour is not caused by user error, it is concerning to learn that the issue is a result of using the backup tool.

[gerald_clark]

The backup tool just uses tar.
I think you are barking up the wrong tree.

[SamK]

The backup tool just uses tar.
I think you are barking up the wrong tree.

Even though the problem originates from tar the behaviour is still encountered as a result of using the backup tool.

[gerald_clark]

Tar does not change the user ids.
I would suspect the Gnome-Mplayer tcz  tce.installed script.

[SamK]

Tar does not change the user ids.
I would suspect the Gnome-Mplayer tcz  tce.installed script.

Have a read of the topic linked in reply #5 above.  It is also confirmed that tar is the originator of the behaviour in this reply http://forum.tinycorelinux.net/index.php/topic,12361.msg66764.html#msg66764.

[tinypoodle]

The backup tool just uses tar.
I think you are barking up the wrong tree.

Even though the problem originates from tar the behaviour is still encountered as a result of using the backup tool.

Yes, but... reading through linked subject related thread it seems likely that the behaviour is encountered as a result of reversing defaults when using the backup tool - i.e. deleting "home" from filetool.lst and subsequently adding subdirs of "home", rather than having "home" included as provided and then adding subdirs and files to xfiletool.lst.

Perhaps it might be considered to add a comment to filetool.lst to create awareness that such a configuration is not fully supported.

[AmatCoder]

Tar does not change the user ids.

Tar does not preserve ownership of path folders when extracting...Only ownership of last item in path is preserved (this item is the only truly archived).
As filetool.sh use sudo tar then folders in path are created with root:staff ownership.

[AmatCoder]

Yes, but... reading through linked subject related thread it seems likely that the behaviour is encountered as a result of reversing defaults when using the backup tool - i.e. deleting "home" from filetool.lst and subsequently adding subdirs of "home", rather than having "home" included as provided and then adding subdirs and files to xfiletool.lst.

If you want to backup only a few items from home directory, it's easier to add those items individually to filetools, instead to add all others to xfiletools.

[tinypoodle]

If you want to backup only a few items from home directory, it's easier to add those items individually to filetools, instead to add all others to xfiletools.

It's difficult to follow a reasoning of "it's easier" for a method which has been shown to lead to undesirable result and requires manual file permission corrections after each restore.
Perhaps you mean to say that it would be easier if your reversed method would have the same reliability and would lead to same result as the default method - which is obviously not the case.
GNU tar would allow fine grain control options regarding file permissions which busybox tar does not.

Here's a different approach to what you try to achieve:

Code: [Select]

/bin/ls -d1 /home/tc/.* >>/opt/.xfiletool2.lst && /bin/ls -d1 /home/tc/* >>/opt/.xfiletool2.lst && sed -i 's/\(.\{1\}\)//;/[./][.]*$/d' /opt/.xfiletool.lst
That should append all files and dirs in /home/tc to .xfiletool.lst and then you can just delete entries from .xfiletool.lst instead of deleting /home/tc and adding single file/dir entries.