Re: Home directory files invisible!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Actually it meant the "text" segment (code and constant data) was
> write-protected during execution, and hence could be shared between
> multiple processes executing the same program. In fact that's why it was
> called the "sticky" bit -- the text segment could stick in RAM even if
> the process was swapped out, and in fact never needed to be swapped out
> because it could always be reloaded from the executable file. This is
> now assumed in the case of modern paging systems, but in the old PDP-11
> it wasn't available on all models and could in some corner cases reduce
> the total amount of virtual memory available to the process (you only
> had a total of 8 physical segments of up to 32Kb each, and the stack
> took up at least 1; later models allowed 16 segments total but 8 could
> only be text and 8 could only be data or stack). Hence it had to be
> user-modifiable.

[although you needed a later 2.x BSD to utilise anything beyond 64K code
64K data. 2BSD could do segment handling stuff [think DOS EMS and try not
to get flashbacks from the horror]

> Now I'm showing my age :-)

The V7 manual doesn't quite agree with you. The sticky bit simply
indicates that the code segment for the binary should be kept around in
memory/swap (fast storage) not discarded. It might get set on a tiny
number of root apps to tune performance.

Anyone who remembers "resident" on the Amiga has the right idea.

It did require on the 11 that the program was split I/D so there was an
unmodifiable code segment but that's an implementation detail for that
architecture. Some Unixen today still honour the sticky bit for
executables - but not many.

As it was only relevant for executables it also got borrowed for other
bits. For directories it indicates that only the file owner can
unlink(remove) files - mostly to fix /tmp. A couple of systems use
it for other 'magic' on non-executable files.

Alan
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux