Re: Curious Sunday Morning Linux File System Question ??

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


On Mon, 2007-03-12 at 17:35 +1300, Shams wrote:
> Hi,
> My question would be:
> Is it the kernel or the shell and other user land program eg. bash,
> ls, rm responsible for hiding the dotted files?
> Historically:
> Now why is this not just a attribute (like the evil OS Windows does)
> or permission of the file instead of using obsure file names ie. the dot
> prefix to hide the file?
> Thanks
> Shams
> -- 
> "Mikkel L. Ellertson" <[email protected]> wrote in message 
> news:[email protected]
> > William Case wrote:
> >> Hi All;
> >>
> >> Just did some changes in my ~/.* ( dot files ) and started wondering why
> >> Linux uses dot files for its 'user' data.  Its a small annoyance to have
> >> to specify .* each time I use them.  The annoyance is primarily not
> >> because it's difficult but because it is odd -- different from anything
> >> else and data files get mixed (kinda) with my working documents.  Why
> >> not just have a standard additional directory for 'config', or whatever
> >> name, to hold all the user application type data.  Is the reason
> >> historical or is there a pragmatic purpose?
> >>
> > This is the way Linux hides files and directories. You will notice
> > that they do not show up in a normal ls listing, or in the file
> > selection window of most programs. If you have your file manager set
> > up not to show hidden files/directories, they will not show up there
> > ether

Originally Unix used teletypes for interface and paper tape for program
loads.  Thus the ascii character set without lower case.  This is
handled by 7 bits (and can be handled by 5 bits).  Thus a character
would not have the bit 7.  The reason this is important is that in
Microsoft, as in CPM, the msb of the first three characters of the file
name stores the read only, archive and hidden attributes.  Since the
character set didn't include extra bits, the period accomplished the job
and was more visible to the root users who administered the system.  

	Other schemes have been used, one was a header that contained all kinds
of attributes in a highly secure system.  Apple used to use a "fork"
which had a short file that contained attribute and application
information on each file but was stored separately for compatibility
with main frame and minicomputer systems.  An old Cyber system used a
list that followed the file.  I don't recall now how DG and DEC handled
it, but they had their own systems as well, but almost everyone
recognized that it was necessary to have files that the typical user
didn't need to see, that had to have a convenient location on a per/user
basis (the users home directory), and that could easily be recovered,
moved copied and controlled by system administrators.  

	Of all the systems I have used the Unix form seems the least
restrictive, simplest to implement, and sufficiently robust.  In other
words, once you become familiar with it, you will prefer it to most
other methods.  YMMV.

	Unix also used to have a generally accepted practice that all user
config files were to be in straight text, so they could be human
readable.  I am happy to see that Linux seems to be retaining that
philosophy.  Microsoft brought so much misery with their encoded classes
and binary formats that I hated it whenever one of the people I worked
with had a problem on their systems.  I admired grately the one
administrator who had enough seniority to put a placard in her window
that said, " I don't do windows!".  My personal opinion, but apparently

Les H

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux