Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: SamK on October 24, 2010, 11:48:38 AM
-
In TC 3.1, LXDE2 + GVFS is installed. In PCmanFM 0.9.7 Menu Go->Network Drives produces an error message:
Error
Operation not supported
In Lubuntu 10.10 this works by automatically creating directories (mounts?) to the remote shares in ~/.gvfs, which is not present in the /home/tc directory. Are there other extensions required by TC3.1 that are not listed as dependencies of LXDE2 and GVFS?
-
mounting on ~/.gvfs causes tiny core backup fail all the time so i had to compile gvfs without fuse support
-
mounting on ~/.gvfs causes tiny core backup fail all the time so i had to compile gvfs without fuse support
OK.
A few questions from the perspective of a non-maintainer/non-coder as I am quite curious.
Have I understood correctly that the issue does not apply in circumstances where filetool.sh is not used, i.e. when a persistent home is employed? If so, is there a case for having a version to be used only when filetool.sh is not used to backup a persistent home directory? I can see that from a package maintainers point of view offering two versions is less desirable than a single package and fully accept it is entirely your choice to make.
Without the benefit of the testing you conducted I may not have grasped the reason for the incompatibility of the Tinycore backup with ~/.gvfs. Is it not possible to exclude ~/.gvfs from the backup via xfiletool.lst? When GVFS is listed in OnBoot ~/.gvfs will then be (re)created in the same condition (unpopulated) as when initially downloaded and installed from the TC repository. The remote network shares will then be found (again) and mounts (re)created for them in ~/.gvfs. Is this an overly simplistic view of the issue?
-
adding ~/.gvfs to backup exclude list does not help unfortunately
and backup/restore is a tiny core standart so i can not force people to remove home from backup but i prefer something that just works for everyone as a package maintainer
-
maybe this could be soved if shutdown.sh would be executed before the backup
-
...i can not force people to remove home from backup...
I wonder If we may have a language difficulty here. Perhaps my clumsy manner of expressing my ideas mistakenly led you you think this is what I was suggesting.
...i prefer something that just works for everyone as a package maintainer
I fully support this point of view. It is regrettable that it can only be achieved by dropping one of the most attractive features of the app. I feel sure that automatic discovery and mounting of remote network shares would be welcomed by both users and non-users of filetool.sh.
adding ~/.gvfs to backup exclude list does not help unfortunately
and backup/restore is a tiny core standart...
Well... there is (may be?) an implicit acknowledgement that not all TC users will be running filetool.sh. shutdown.sh tests to see if a backup has been conducted or not.
#!/bin/sh
# put user shutdown commands here
# If no backup of home was done then loop through valid users to clean up.
if [ ! -e /tmp/backup_done ] || ! grep -q "^home" /opt/.filetool.lst; then
...
I am unaware of the the extent of the problem with GVFS and filetool.sh, and will probably be of little assistance with it. Might it be worth sharing your findings with the TC team to see if it can be resolved. Its inclusion by default in Lubuntu indicates there is a perceived benefit within another (albeit not quite so) minimalistic distro .