Professional Web Applications Themes

separate /bin and /usr/bin - is this just legacy? - Linux / Unix Administration

I've been wondering why it we still have /bin and /usr/bin kept separate? Likewise /lib separate from /usr/lib and /sbin separate from /usr/sbin. It seems like a legacy thing to me when the intent was to have a small set of tools that could maintain the system in single user mode before /usr is mounted. But with huge disk capacities of today, is that even needed? There's plenty of space for a separate partition with a duplicate system. And CDROMs can hold a complete rescue systems that surpass the capabilities of an entire installed system of just a decade ago. ...

  1. #1

    Default separate /bin and /usr/bin - is this just legacy?

    I've been wondering why it we still have /bin and /usr/bin kept separate?
    Likewise /lib separate from /usr/lib and /sbin separate from /usr/sbin.
    It seems like a legacy thing to me when the intent was to have a small set
    of tools that could maintain the system in single user mode before /usr is
    mounted. But with huge disk capacities of today, is that even needed?
    There's plenty of space for a separate partition with a duplicate system.
    And CDROMs can hold a complete rescue systems that surpass the capabilities
    of an entire installed system of just a decade ago. I no longer use single
    user mode for anything and so I can't see any need for structuring things
    specifically to make single user mode workable. Do we really need single
    user mode for newer systems, as opposed to a complete, and totally separate,
    maintenance system (either on another partition or separate media)?

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  2. #2

    Default Re: separate /bin and /usr/bin - is this just legacy?

    The sbin directory are commands that are available only in single user
    mode the /bin directory is multi-user mode.

    patlav@gmail.com Guest

  3. #3

    Default Re: separate /bin and /usr/bin - is this just legacy?

    net wrote: 

    Solaris has been known to replace /bin and /lib with symbolic links,
    so it is easy to view the difference as legacy. The strict need for
    separation is in the past. There's more to life than needs based on
    old hardware types.
     

    Ah, now there's where your bias comes in.
     

    A small booting system exists. Whether it's only used for stuff like
    jumpstart/kickstart/ignite. It makes little sense for a separate
    system
    to be used when a pared-down version can be used. Of course, the
    only time that's needed in any strict sense is boot time.

    There's more than "need", though. There can be other advantages. I
    like to side-step the actual history of the name of /usr and teach
    that it has newer meaning. USR for Unix System Reserved or even
    better Unix System Readonly. There is plenty of use to having the
    filesystem that contains the bulk of the installation to be read-only.
    Whether that means logically RO from strict permissions, virtually
    RO from being mounted RO except to do installs, or physically RO
    once installation is finished isn't as relevant as the idea that it can
    be treated as read-only.

    Someday over the rainbow, viruses will attack UNIX. At that time
    the more systems that have the more layers of protection the better.
    Isolating the least changing parts of the installation, and the most
    crucial parts of the installation and making them RO is yet another
    layer of defense in depth. The stricter the level or RO-ness the
    less suseptible to attack.

    Whether there's a separate / and /usr isn't a big deal to me. Making
    /usr as locked down as feasible is. Try going to the extreme of
    making / and /usr together and to making it RO in hardware and
    see what happens - /etc is a problem. Files in /etc need to change
    with some frequency. Separate / and /usr works. Having /etc as a
    separate mount doesn't because of assumptions built into the
    system. How to find /etc/vfstab or /etc/filesystems>

    Doug Guest

  4. #4

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 12 Dec 2005 11:41:45 -0800, com <com> wrote: 

    Since when?
     

    How sure are you of that?

    Dave Guest

  5. #5

    Default Re: separate /bin and /usr/bin - is this just legacy?

    "Doug Freyburger" <com> writes:
     [/ref]
     

    We still support a separate / & /usr in Solaris though; and in Solaris 10
    /lib is no longer a symbolic link but it's the directory with all shared
    libraries needed for initial bootstrap (i.e., a lot of them)
     

    Quite. While we now generally recommend having a merged / & /usr,
    we understand there are those who have reasons to split the two.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  6. #6

    Default Re: separate /bin and /usr/bin - is this just legacy?

    Dave Hinz wrote: 
    >
    > Since when?[/ref]

    The S in sbin stands for Statically linked, or at least it started out
    standing for that. Not for Single user mode. It's since people
    started
    making the mistake of picking the wrong meaning for S.

    Why did vendors start shipping dynamic binaries in either sbin? I
    suggest the answer "by mistake".

    Doug Guest

  7. #7

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 12 Dec 2005 13:32:13 -0800, Doug Freyburger <com> wrote: 
    >>
    >> Since when?[/ref]
    >
    > The S in sbin stands for Statically linked, or at least it started out
    > standing for that. Not for Single user mode.[/ref]

    That's what I thought, but you never know sometime.
     
     

    Ignorace, you mean?

    Dave Guest

  8. #8

    Default Re: separate /bin and /usr/bin - is this just legacy?

    "Doug Freyburger" <com> writes:
     
    >>
    >> Since when?[/ref][/ref]
     

    This would seem there's some burden of proof that "sbin" post-dates
    dynamic linking.
     

    Because the purpose changed....

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  9. #9

    Default Re: separate /bin and /usr/bin - is this just legacy?

    In comp.unix.admin Dave Hinz <net>: 
    >>
    >> The S in sbin stands for Statically linked, or at least it started out
    >> standing for that. Not for Single user mode.[/ref][/ref]
     

    Really? Always was under the impression the "s" in "sbin" stands
    for superuser bin, because it's in root's path.

    Out of curiosity just run ldd /sbin/* on a sun box (5.10) and
    most if not anything is dynamically linked, so it doesn't support
    the theory of statically linked.

    A check on HP-UX (11.11) shows most things in /sbin aren't
    dynamically linked but in /usr/sbin they are.

    FreeBSD (4.11) has lots of binaries statically linked in /sbin,
    but a few are dynamically.

    Linux shows more dynamically linked binaries then statically in
    /sbin, but both are available.

    Without trying out others, the behavior doesn't seem to be
    consistent at all no matter if it's UNIX[tm] or not, so I'll
    happily stay with the definition of "sbin == superuser bin",
    which seems to make at least more sense to me.

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 174: Backbone adjustment
    Michael Guest

  10. #10

    Default Re: separate /bin and /usr/bin - is this just legacy?

    Michael Heiming <michael+heiming.de> writes:
     

    Solaris 10 doesn't support static linking at all. But even on
    Solaris 9 most stuff under /sbin is dynamically linked, but
    with a separate library/linker from /etc/lib.

    /usr/sbin is normally dynamically linked, except for what's
    in /usr/sbin/static (which is no longer present in S10)

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  11. #11

    Default Re: separate /bin and /usr/bin - is this just legacy?

    In comp.unix.admin Casper H.S. Dik <com>: 
     [/ref]
     
     

    This info seems to add that the meaning of the "s" in sbin isn't
    statically, if at all only historically might make some sense.

    The single user theory doesn't make much sense, even if iirc
    Tru64 has some things statically linked in /sbin if you are
    missing other fs in single user mode, but it shouldn't stop you
    from running /sbin/bcheckrc to make them available if possible.

    Still the "s" == "superuser" makes most sense to me.

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 254: Interference from lunar radiation
    Michael Guest

  12. #12

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On Tue, 13 Dec 2005 13:07:12 +0100, Michael Heiming <michael+heiming.de> wrote: [/ref]
     [/ref][/ref]
     [/ref]
     

    Hm, never made that connection. If my books weren't packed right now
    I'd check out my copy of "Life with Unix" which may talk of the origins
    of the /sbin name.
     

    I think it used to be that way and people lost track of the intent.
     

    You can call it "superman bin" if you want, since it seems nobody is
    real clear on the actual origins at this point in this group. Could be
    one of those "used to have a reason" type things. Unix has a couple of
    those...

    Dave Guest

  13. #13

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 12 Dec 2005 11:41:45 -0800 com wrote:

    | The sbin directory are commands that are available only in single user
    | mode the /bin directory is multi-user mode.

    However, I'm not comparing /bin to /sbin, nor /usr/bin to /usr/sbin.
    Instead, I am comparing /bin to /usr/bin, and /sbin to /usr/sbin.
    Big difference.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  14. #14

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 12 Dec 2005 13:32:13 -0800 Doug Freyburger <com> wrote:
    | Dave Hinz wrote:
    |> com wrote:
    |>
    |> > The sbin directory are commands that are available only in single user
    |> > mode
    |>
    |> Since when?
    |
    | The S in sbin stands for Statically linked, or at least it started out
    | standing for that. Not for Single user mode. It's since people
    | started
    | making the mistake of picking the wrong meaning for S.
    |
    | Why did vendors start shipping dynamic binaries in either sbin? I
    | suggest the answer "by mistake".

    Probably because they might have thought "s" meant single or system.
    I once thought the latter.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  15. #15

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 12 Dec 2005 11:53:27 -0800 Doug Freyburger <com> wrote:

    | net wrote:

    |> There's plenty of space for a separate partition with a duplicate system.
    |> And CDROMs can hold a complete rescue systems that surpass the capabilities
    |> of an entire installed system of just a decade ago. I no longer use single
    |> user mode for anything and so I can't see any need for structuring things
    |> specifically to make single user mode workable.
    |
    | Ah, now there's where your bias comes in.

    I won't say I'm not biased. But maybe you can describe what bias
    you see. Is it that I use Linux?


    |> Do we really need single
    |> user mode for newer systems, as opposed to a complete, and totally separate,
    |> maintenance system (either on another partition or separate media)?
    |
    | A small booting system exists. Whether it's only used for stuff like
    | jumpstart/kickstart/ignite. It makes little sense for a separate
    | system
    | to be used when a pared-down version can be used. Of course, the
    | only time that's needed in any strict sense is boot time.

    My separate system is "complete" enough to be quite usable for doing
    a lot of things. It is focused on doing administration. It does have
    emacs, for example. But it doesn't have Solitaire to pass the time
    while disks are reformatted :-) It is on a 248 MB partition while
    the main system has 4 GB for /usr and some other stuff.


    | There's more than "need", though. There can be other advantages. I
    | like to side-step the actual history of the name of /usr and teach
    | that it has newer meaning. USR for Unix System Reserved or even
    | better Unix System Readonly. There is plenty of use to having the
    | filesystem that contains the bulk of the installation to be read-only.
    | Whether that means logically RO from strict permissions, virtually
    | RO from being mounted RO except to do installs, or physically RO
    | once installation is finished isn't as relevant as the idea that it can
    | be treated as read-only.

    Actually, I have been mounting /usr RO for years. It is interesting
    that you bring this up, because I want to also have what's in /bin be
    RO as well.


    | Someday over the rainbow, viruses will attack UNIX. At that time
    | the more systems that have the more layers of protection the better.
    | Isolating the least changing parts of the installation, and the most
    | crucial parts of the installation and making them RO is yet another
    | layer of defense in depth. The stricter the level or RO-ness the
    | less suseptible to attack.

    That's why I want /bin, and /lib, and /sbin, to all be RO, in addition
    to /usr and even /opt (where used).


    | Whether there's a separate / and /usr isn't a big deal to me. Making
    | /usr as locked down as feasible is. Try going to the extreme of
    | making / and /usr together and to making it RO in hardware and
    | see what happens - /etc is a problem. Files in /etc need to change
    | with some frequency. Separate / and /usr works. Having /etc as a
    | separate mount doesn't because of assumptions built into the
    | system. How to find /etc/vfstab or /etc/filesystems>

    What I'm experimenting with in Linux right now is making / be tmpfs
    (e.g. lives in RAM but is swappable) and mounting everything else to
    that. By using the "bind" option of mount, I can mount specific
    directories of one filesystem as /bin, /lib, /sbin, and /usr. And
    it is RO. So is / for that matter. So how did I deal with /etc?
    And what about /dev? Those are similarly bind mounted along with
    most of /var on another filesystem, which stays RW. Some other things
    have their own tmpfs or filesystem. Here's what I have running with
    Linux and derived from Slackware:

    rootcanopus:/root 1> df -a
    Filesystem 1K-blocks Used Available Use% Mounted on
    tmpfs[root] 1024 0 1024 0% /
    /dev/hda1 248944 167280 81664 68% /admin
    /dev/hda3:bin 4075456 3844784 230672 95% /bin
    /dev/hda1:boot 248944 167280 81664 68% /boot
    /dev/hda5:dev 128440 65192 63248 51% /dev
    devpts 0 0 0 - /dev/pts
    tmpfs[shm] 193032 0 193032 0% /dev/shm
    /dev/hda5:etc 128440 65192 63248 51% /etc
    /dev/hda4:home 113631392 96863892 16767500 86% /home
    /dev/hda3:lib 4075456 3844784 230672 95% /lib
    /dev/hda3:opt 4075456 3844784 230672 95% /opt
    proc 0 0 0 - /proc
    /dev/hda5:root 128440 65192 63248 51% /root
    /dev/hda3:sbin 4075456 3844784 230672 95% /sbin
    sysfs 0 0 0 - /sys
    /dev/hda7:tmp 642536 37940 604596 6% /tmp
    /dev/hda3:usr 4075456 3844784 230672 95% /usr
    /dev/hda5:var 128440 65192 63248 51% /var
    tmpfs[lock] 193032 0 193032 0% /var/lock
    /dev/hda8:log 128440 47548 80892 38% /var/log
    tmpfs[run] 193032 96 192936 1% /var/run
    /dev/hda6:var/mail 128440 32840 95600 26% /var/mail
    /dev/hda7:var/tmp 642536 37940 604596 6% /var/tmp
    /dev/hda4:web 113631392 96863892 16767500 86% /web
    rootcanopus:/root 2>

    These are RO: tmpfs[root], /dev/hda1, /dev/hda3.

    And /dev/hda1 is that "complete" enough system I mentioned above. It is
    also where the kernel image resides (a practice I started back when the
    528 MB boundary on PC partitions was an issue for boot loading).

    I certainly have /bin and /usr/bin on the same filesystem. This is part
    of why I wonder why I can't just do away with the difference altogether.
    I may well just have to try it and see what happens (although that won't
    really tell me if it would break common situations that I just happen to
    not have).

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  16. #16

    Default Re: separate /bin and /usr/bin - is this just legacy?

    net wrote: 

    "I no longer use single user mode for anything". If you use kickstart,
    if you boot, you use single user mode for something. That's the
    bias. I've used single user mode for rescue work a lot over the years
    before CDROM rescue disks came into existance. I *love* the fact
    that they exist now, but I still get that I use single user mode rather
    I do so actively or not.
     

    Is emacs in your kickstart image or just the larger rescue CDROM?
    Just checking - You run emacs in the mode that overwrites the file
    using the same inode sysadmin style, right? As opposed to the
    standard developer mode where it renames the original and writes
    the new version separately.
     

    That's what Nethack is for not Solitaire! Of course if you're going
    to be formatting disks while playing Nethack it better be a long
    line of racks of fully stuffed huge EMC arrays ...
     

    Excellent. This ties in with the name meanings of sbin. The first
    sbin
    on a Solaris machine was populated with startically linked binaries,
    so it might have originally meant static. But it was quickly split and
    populated with dynamically linked binaries, so it evolved to mean
    sysadmin.
     

    The lesson of Solaris is /bin can be a sym-link.
     

    init is compiled with /etc/inittab in it. The /etc directory appears
    in
    the compiled binary of at least one other boot-time executible. At
    least getting to /etc/fstab in the first place is a problem - Fix with
    a
    copy in the parent filesystem then mount over it?

    The problem of /dev is solved somehow in the Solaris jumpstart
    process so is likely solved somehow in the Linux kickstart process.

    Doug Guest

  17. #17

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 14 Dec 2005 09:11:53 -0800 Doug Freyburger <com> wrote:
    | net wrote:
    |> Doug Freyburger wrote:
    |> | net wrote:
    |>
    |> |> There's plenty of space for a separate partition with a duplicate system.
    |> |> And CDROMs can hold a complete rescue systems that surpass the capabilities
    |> |> of an entire installed system of just a decade ago. I no longer use single
    |> |> user mode for anything and so I can't see any need for structuring things
    |> |> specifically to make single user mode workable.
    |>
    |> | Ah, now there's where your bias comes in.
    |>
    |> I won't say I'm not biased. But maybe you can describe what bias
    |> you see. Is it that I use Linux?
    |
    | "I no longer use single user mode for anything". If you use kickstart,
    | if you boot, you use single user mode for something. That's the
    | bias. I've used single user mode for rescue work a lot over the years
    | before CDROM rescue disks came into existance. I *love* the fact
    | that they exist now, but I still get that I use single user mode rather
    | I do so actively or not.

    I used to use single user mode for rescue and fixup purposes, such as
    when /usr would fail to mount, or libraries got misconfigured, or
    whatever.

    BTW, I have machines with no removable media drive at all. I have a
    rescue partition configured in. But it is definitely more than just
    single user mode. It comes up without any production system filesystem
    mounted.


    |> |> Do we really need single
    |> |> user mode for newer systems, as opposed to a complete, and totally separate,
    |> |> maintenance system (either on another partition or separate media)?
    |>
    |> | A small booting system exists. Whether it's only used for stuff like
    |> | jumpstart/kickstart/ignite. It makes little sense for a separate
    |> | system
    |> | to be used when a pared-down version can be used. Of course, the
    |> | only time that's needed in any strict sense is boot time.
    |>
    |> My separate system is "complete" enough to be quite usable for doing
    |> a lot of things. It is focused on doing administration. It does have
    |> emacs, for example.
    |
    | Is emacs in your kickstart image or just the larger rescue CDROM?

    I do have some rescue CDROMs, and yes, emacs is in most of them.
    It is in my rescue partition, as well.


    | Just checking - You run emacs in the mode that overwrites the file
    | using the same inode sysadmin style, right? As opposed to the
    | standard developer mode where it renames the original and writes
    | the new version separately.

    I prefer write new and rename even for sysadmin work. I can do the
    former if I need it.


    |> | There's more than "need", though. There can be other advantages. I
    |> | like to side-step the actual history of the name of /usr and teach
    |> | that it has newer meaning. USR for Unix System Reserved or even
    |> | better Unix System Readonly. There is plenty of use to having the
    |> | filesystem that contains the bulk of the installation to be read-only.
    |> | Whether that means logically RO from strict permissions, virtually
    |> | RO from being mounted RO except to do installs, or physically RO
    |> | once installation is finished isn't as relevant as the idea that it can
    |> | be treated as read-only.
    |>
    |> Actually, I have been mounting /usr RO for years.
    |
    | Excellent. This ties in with the name meanings of sbin. The first
    | sbin
    | on a Solaris machine was populated with startically linked binaries,
    | so it might have originally meant static. But it was quickly split and
    | populated with dynamically linked binaries, so it evolved to mean
    | sysadmin.

    Or you gave another word we could claim it might mean: split :)


    |> It is interesting
    |> that you bring this up, because I want to also have what's in /bin be
    |> RO as well.
    |
    | The lesson of Solaris is /bin can be a sym-link.

    Then I see no reason it can't be in Linux or BSD, either. And at least
    in Linux, I could bind-mount instead of sym-link, too.


    |> What I'm experimenting with in Linux right now is making / be tmpfs
    |> (e.g. lives in RAM but is swappable) and mounting everything else to
    |> that. By using the "bind" option of mount, I can mount specific
    |> directories of one filesystem as /bin, /lib, /sbin, and /usr. And
    |> it is RO. So is / for that matter. So how did I deal with /etc?
    |> And what about /dev? Those are similarly bind mounted along with
    |> most of /var on another filesystem, which stays RW. Some other things
    |> have their own tmpfs or filesystem. Here's what I have running with
    |> Linux and derived from Slackware:
    |
    | init is compiled with /etc/inittab in it. The /etc directory appears
    | in

    That can be convenient, or inconvenient, depending on the situation.
    Probably more the former.


    | the compiled binary of at least one other boot-time executible. At
    | least getting to /etc/fstab in the first place is a problem - Fix with
    | a
    | copy in the parent filesystem then mount over it?

    I'm experimenting with my oen boot-time pre-init (a program that runs in
    PID 1 before the real init is executed) that effectively include /etc/fstab.
    It is programmed with an exact sequence of steps to setup the namespace I
    am working with right now. It's where I'm doing a lot of tweaking.


    | The problem of /dev is solved somehow in the Solaris jumpstart
    | process so is likely solved somehow in the Linux kickstart process.

    Solaris on Sparc has some advantages with what I considered a more advanced
    PROM system, as compared to a PC BIOS. I've never tried Solaris on a PC so
    I don't know how it handles that. I suspect it would have to fake some
    stuff and move on.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  18. #18

    Default Re: separate /bin and /usr/bin - is this just legacy?

    net wrote: 

    An exercise for beginners:

    Once you can explain why it's a bad idea to use emacs in its
    default mode of creating a new inode, you're qualified to use it
    in that mode. Yet somehow the SAs who use it in the default
    mode are the ones who can't articulate why it's a bad idea.

    Phil's other writings suggests this would be an easy exercise
    for him. ;^)

    Doug Guest

  19. #19

    Default Re: separate /bin and /usr/bin - is this just legacy?

    On 16 Dec 2005 10:33:40 -0800 Doug Freyburger <com> wrote:
    | net wrote:
    |> Doug Freyburger wrote:
    |>
    |> | Just checking - You run emacs in the mode that overwrites the file
    |> | using the same inode sysadmin style, right? As opposed to the
    |> | standard developer mode where it renames the original and writes
    |> | the new version separately.
    |>
    |> I prefer write new and rename even for sysadmin work. I can do the
    |> former if I need it.
    |
    | An exercise for beginners:
    |
    | Once you can explain why it's a bad idea to use emacs in its
    | default mode of creating a new inode, you're qualified to use it
    | in that mode. Yet somehow the SAs who use it in the default
    | mode are the ones who can't articulate why it's a bad idea.
    |
    | Phil's other writings suggests this would be an easy exercise
    | for him. ;^)

    There are some disadvantages in a few cases, but really, there is no
    overwhelming cause to change the mode.

    One disadvantage of writing the same inode in place is that a file
    may try to read it while the writing is in progress, and get a partial
    content. Of course, if the program doesn't re-open the file to read
    again, it won't see the new inode.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  20. #20

    Default Re: separate /bin and /usr/bin - is this just legacy?

    net wrote: 

    So user/group ownerships, regular permissions and set-uid/gid
    values don't mean anything to you when editting files in /etc or
    elsewhere? Ouch. All of those are lost with the emacs default
    of rename/rewrite. Doing that emacs uses the defaults of your
    current process not what the settings of the original file are. Also
    symlinks get replaced with a file so the place the symlink points
    isn't what is editted.

    Doug Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Legacy saving
    By Joy_Hinckley@adobeforums.com in forum Adobe Illustrator Windows
    Replies: 5
    Last Post: July 1st, 11:44 PM
  2. Legacy Problem?
    By TYP3G1RL@adobeforums.com in forum Adobe Illustrator Macintosh
    Replies: 1
    Last Post: February 14th, 12:26 AM
  3. Legacy Applications
    By Devin in forum Windows Setup, Administration & Security
    Replies: 5
    Last Post: August 11th, 06:26 PM
  4. Legacy Parallel PCI
    By Bob Bailin in forum SCO
    Replies: 0
    Last Post: July 16th, 01:35 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139