WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Persistent Home  (Read 4040 times)

Offline softwaregurl

  • Suspended
  • Full Member
  • ***
  • Posts: 109
Persistent Home
« on: January 04, 2009, 09:08:11 AM »
Quote
The very first use of this code will automatically setup /home/tc to "bind" to /mnt/hdXY/tchome By using this option, you are not having to wait for a backup/restore for those items in your /home/tc directory.
Would it be possible for TCB to bind  /home instead of /home/tc.  This would make it easier for a  multiuser setup.  As it is, I guess I would have to bind each additional users home or have them in the backup.
(And calling it Persistent Home is a bit of a misnomer when it's really Persistent Home/tc  ;).)
Old wounds that have never healed need to be re-exposed before the cure can be applied.  The cure must be available before the wound is re-exposed.

Offline mikshaw

  • Sr. Member
  • ****
  • Posts: 368
Re: Persistent Home
« Reply #1 on: January 04, 2009, 05:35:53 PM »
I don't disagree with you.  This behavior was developed in DSL and I thought it was kind of annoying since I was trying to share a home directory between distributions and ended up making a bunch of symlinks.

You can do it yourself, though, by mounting home from /opt/bootlocal.sh

Offline softwaregurl

  • Suspended
  • Full Member
  • ***
  • Posts: 109
Re: Persistent Home
« Reply #2 on: January 04, 2009, 07:07:10 PM »
Quote
You can do it yourself, though, by mounting home from /opt/bootlocal.sh
I did that myself with DSL.   I could also find the file that binds to home/tc and remaster, but then I would have to remaster every release (and verify that it causes no problems).

It looks to me like just changing one mount command in a startup script?  I guess I'm fishing for any technical reason that it wouldn't work.
Old wounds that have never healed need to be re-exposed before the cure can be applied.  The cure must be available before the wound is re-exposed.

Offline tobiaus

  • Suspended
  • Hero Member
  • *****
  • Posts: 599
Re: Persistent Home
« Reply #3 on: January 04, 2009, 10:54:03 PM »
i'm not going to do much to argue against greater multiuser support (the less it takes the better, but it sounds nice) but i will poke at the "misnomer" statement. /home/tc is the "home folder," of user tc... /home is just where each user's "home folder" goes. but if you want to use the word "misleading..." i guess "misnomer" sounds more friendly (even if it's not one,) so that makes sense.

and the obligatory "appeal to wikipedia" fallacy:
The name of the home directory depends on the operating system, but there appears to be some convergence in recent years. In all cases "name" is the users name or id.

    * /home/name - most distributions of Linux, most variants of BSD (e.g. OpenBSD), and Solaris

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10149
Re: Persistent Home
« Reply #4 on: January 05, 2009, 01:22:57 AM »
I'd like to point out that if you want another username, but still a single user system, if you boot with user=myusername the directory mounted is /home/myusername. Of course this is not a solution for true multiuser support.
The only barriers that can stop you are the ones you create yourself.

Offline mikshaw

  • Sr. Member
  • ****
  • Posts: 368
Re: Persistent Home
« Reply #5 on: January 05, 2009, 05:53:37 AM »
Quote
It looks to me like just changing one mount command in a startup script?  I guess I'm fishing for any technical reason that it wouldn't work.
I can't think of any reason why it couldn't be done, but there might be issues if you're trying to combine things like extensions and backups on the same partition as /home.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Persistent Home
« Reply #6 on: January 11, 2009, 11:26:54 AM »
Implemented in 1.1. But better use persistent home if you have more than one user otherwise you will have issues with backup. TC's focus is not multi-user nor to support persistency. However, the requested change does not change the recommended default usage.
10+ Years Contributing to Linux Open Source Projects.