<br><br><div><span class="gmail_quote">On 3/11/07, <b class="gmail_sendername"><a href="mailto:fedora-list-request@redhat.com">fedora-list-request@redhat.com</a></b> <<a href="mailto:fedora-list-request@redhat.com">fedora-list-request@redhat.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Date: Mon, 12 Mar 2007 06:08:51 +0100<br>From: Walter Garcia-Fontes <
<a href="mailto:walter.garcia@upf.edu">walter.garcia@upf.edu</a>><br>Subject: Re: Problem with external USB hard drive<br>To: For users of Fedora <<a href="mailto:fedora-list@redhat.com">fedora-list@redhat.com</a>>
<br>Message-ID: <<a href="mailto:20070312050851.GB10584@upf.edu">20070312050851.GB10584@upf.edu</a>><br>Content-Type: text/plain;       charset=utf-8<br><br>* Andrig T. Miller [12/03/07 04:00]:<br>>    the automount to work?  Is there something with the disklabel that causes
<br>>    the automount to work and show it as a drive on the desktop?  I thought it<br>>    would work regardless of the file system on it, but I guess not.<br><br>Have you relabelled the disk with, for instance, e2label?
</blockquote><div><br>No, but I just did that, and everything worked like it did before.  Thanks for the help.  As is often the case, the problem was a simple one.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
--<br>Walter Garcia-Fontes<br>Barcelona<br><br><br><br><br>------------------------------<br><br>Message: 15<br>Date: Sun, 11 Mar 2007 22:36:31 -0700<br>From: Les <<a href="mailto:hlhowell@pacbell.net">hlhowell@pacbell.net
</a>><br>Subject: Re: Curious Sunday Morning Linux File System Question ??<br>To: For users of Fedora <<a href="mailto:fedora-list@redhat.com">fedora-list@redhat.com</a>><br>Message-ID: <<a href="mailto:1173677792.8904.13.camel@localhost.localdomain">
1173677792.8904.13.camel@localhost.localdomain</a>><br>Content-Type: text/plain<br><br>On Mon, 2007-03-12 at 17:35 +1300, Shams wrote:<br>> Hi,<br>><br>> My question would be:<br>><br>> Is it the kernel or the shell and other user land program eg. bash,
<br>> ls, rm responsible for hiding the dotted files?<br>><br>> Historically:<br>> Now why is this not just a attribute (like the evil OS Windows does)<br>> or permission of the file instead of using obsure file names ie. the dot
<br>> prefix to hide the file?<br>><br>> Thanks<br>> Shams<br>><br>> --<br>><br>> "Mikkel L. Ellertson" <<a href="mailto:mikkel@infinity-ltd.com">mikkel@infinity-ltd.com</a>> wrote in message
<br>> news:45F4229E.6050106@infinity-ltd.com...<br>> > William Case wrote:<br>> >> Hi All;<br>> >><br>> >> Just did some changes in my ~/.* ( dot files ) and started wondering why<br>> >> Linux uses dot files for its 'user' data.  Its a small annoyance to have
<br>> >> to specify .* each time I use them.  The annoyance is primarily not<br>> >> because it's difficult but because it is odd -- different from anything<br>> >> else and data files get mixed (kinda) with my working documents.  Why
<br>> >> not just have a standard additional directory for 'config', or whatever<br>> >> name, to hold all the user application type data.  Is the reason<br>> >> historical or is there a pragmatic purpose?
<br>> >><br>> > This is the way Linux hides files and directories. You will notice<br>> > that they do not show up in a normal ls listing, or in the file<br>> > selection window of most programs. If you have your file manager set
<br>> > up not to show hidden files/directories, they will not show up there<br>> > ether<br><br>Originally Unix used teletypes for interface and paper tape for program<br>loads.  Thus the ascii character set without lower case.  This is
<br>handled by 7 bits (and can be handled by 5 bits).  Thus a character<br>would not have the bit 7.  The reason this is important is that in<br>Microsoft, as in CPM, the msb of the first three characters of the file<br>name stores the read only, archive and hidden attributes.  Since the
<br>character set didn't include extra bits, the period accomplished the job<br>and was more visible to the root users who administered the system.<br><br>        Other schemes have been used, one was a header that contained all kinds
<br>of attributes in a highly secure system.  Apple used to use a "fork"<br>which had a short file that contained attribute and application<br>information on each file but was stored separately for compatibility
<br>with main frame and minicomputer systems.  An old Cyber system used a<br>list that followed the file.  I don't recall now how DG and DEC handled<br>it, but they had their own systems as well, but almost everyone<br>
recognized that it was necessary to have files that the typical user<br>didn't need to see, that had to have a convenient location on a per/user<br>basis (the users home directory), and that could easily be recovered,
<br>moved copied and controlled by system administrators.<br><br>        Of all the systems I have used the Unix form seems the least<br>restrictive, simplest to implement, and sufficiently robust.  In other<br>words, once you become familiar with it, you will prefer it to most
<br>other methods.  YMMV.<br><br>        Unix also used to have a generally accepted practice that all user<br>config files were to be in straight text, so they could be human<br>readable.  I am happy to see that Linux seems to be retaining that
<br>philosophy.  Microsoft brought so much misery with their encoded classes<br>and binary formats that I hated it whenever one of the people I worked<br>with had a problem on their systems.  I admired grately the one<br>
administrator who had enough seniority to put a placard in her window<br>that said, " I don't do windows!".  My personal opinion, but apparently<br>shared.<br><br>Regards,<br>Les H<br><br><br><br><br>------------------------------
<br><br>--<br>fedora-list mailing list<br><a href="mailto:fedora-list@redhat.com">fedora-list@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-list">https://www.redhat.com/mailman/listinfo/fedora-list
</a><br><br>End of fedora-list Digest, Vol 37, Issue 96<br>*******************************************<br></blockquote></div><br>