Date: Tue, 26 Sep 1995 10:45:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: chuckr@eng.umd.edu, julian@ref.tfs.com, richard@harlequin.co.uk, freebsd-install@freebsd.org, freebsd-questions@freebsd.org Subject: Re: "Installation" and "upgrade" Message-ID: <199509261745.KAA07895@phaeton.artisoft.com> In-Reply-To: <22041.812112069@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 03:41:09 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Besides having to deal with a boatload of howls from folks who lost their > > files because they were told they could upgrade without the reinstall, > > how are you going to troubleshoot future reported problems if you aren't > > even sure of the underlying FS ? I don't like this idea ... > > The underlying fs hasn't changed - just the disklabels. There is backward compatability, which is there at what I would call "great expense" because of the endianness choices being made in favor of Motorolla byte order. Specifically, there is now a type hint field in the directory and the size of the length has been reduced from a short to a char, the other char being stolen for the hint field. In the superblock, there are several additional fields that the fsck does not recognize as being there for backward compatability. They store, among other things, the maxsymlinklength. The existance of these fields makes old FS's appear "dirty" on each reboot. Symlinks are allowed to be stored as directory entries rather than having inodes at all. There are semantic differences for links in directories with the sticky bit/SUID/SGID bits set that result from this. Specifically, you can create links for which you do not have priveledges to delete. There are bits which attribute the file: schg file can not be changed uchg file can not be changed; can be unset by root or owner arch file has been archived (root only) dump file should not be archived sappend file can only be appended to uappend file can only be appened to; can be unset by root or owner sappend/schg can only be unset in single user mode. In addition to these changes, the FS in 386BSD did not support the clean flag, and the current and immediately previous FS does. So the FS /has/ changed somewhat. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509261745.KAA07895>