Am 01.10.2012 12:47, schrieb Martin Helm:
> we need a standard body that propagates at least a minimal
> implementataion, like POSIX did.
It seems that http://dublincore.org/ (mentioned on the freedesktop page
for a set of extended attributes) is exactly that.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.1 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
From the freedesktop.org page mentioned earlier:
For example, if you have written a book, your document might include information about it such as number of words, number of characters, number of chapters, and so on. These attributes might be added by your word processor or you might insert them manually using an attribute editor. Since they would change every time you edited the document, you wouldn’t want to include them as a part of your document unless the information was specifically marked as being information about the document (“metadata”) in which case either it’s kept in the document as a special marked internal value (e.g. an attribute) or is stored outside the document as an attribute. The difference being, at least in theory, one could examine the attribute data about a file without changing the last access date/time of that file. Thus information not directly related to the file itself could be stored externally to the file, such as comments, lists of contributors, and so on.
Students regularly come with those ideas, such as redesigning file systems by adding attributes to store any kind of meta information. It doesn’t surprise me that it comes from freedesktop. It is stupid, inefficient, potentially unsafe, as it makes the file system more complicated than it should be.
Am 01.10.2012 13:06, schrieb please try again:
> Students regularly come with those ideas, such as redesigning file
> systems by adding attributes to store any kind of meta information.
In which way is that redesigning, all our standard file systems support
that out of the box for years, and the linux kernel supports that since 2.6.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.1 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
please try again wrote:
> From the freedesktop.org page mentioned earlier:
>
>> For example, if you have written a book, your document might include
>> information about it such as number of words, number of characters,
>> number of chapters, and so on. These attributes might be added by your
>> word processor or you might insert them manually using an attribute
>> editor. Since they would change every time you edited the document, you
>> wouldn’t want to include them as a part of your document unless the
>> information was specifically marked as being information about the
>> document (“metadata”) in which case either it’s kept in the document as
>> a special marked internal value (e.g. an attribute) or is stored outside
>> the document as an attribute. The difference being, at least in theory,
>> one could examine the attribute data about a file without changing the
>> last access date/time of that file. Thus information not directly
>> related to the file itself could be stored externally to the file, such
>> as comments, lists of contributors, and so on.
>
> Students regularly come with those ideas, such as redesigning file
> systems by adding attributes to store any kind of meta information. It
> doesn’t surprise me that it comes from freedesktop. It is stupid,
> inefficient, potentially unsafe, as it makes the file system more
> complicated than it should be.
Dublin Core can be quite useful in the fields of ontology and RSS feeds.
It seems to me that the idea mentioned from the freedesktop page is
pretty much of a non-starter though. Each time the file was updated,
something would have to recalculate all this metadata and update that as
well. Bad enough for a wrod processor that autosaves every five minutes.
What about a program that is appending text to a file continuously (a
newsfeed or similar) or even a logger?
Document management systems exist for when such metadata is needed.
On Sun, 30 Sep 2012 10:06:01 GMT, MirceaKitsune
<MirceaKitsune@no-mx.forums.opensuse.org> wrote:
>
>More of a general Linux question, but since openSUSE is my distribution
>I’m asking here. Like I said I’m moving from Windows 7 to SUSE, and
>inevitably comparing many things on the way. Something I’m slightly
>confused about is the way Linux chooses to mark hidden files / folders
>compared to Win. While in Windows you right-click them and mark them as
>‘hidden’, in Linux they are marked this way by putting a dot in the file
>/ folder name (eg: “.something” instead of “something”).
>
>I’m slightly confused as to why the name is being used to mark things
>as hidden. One feature in Linux compared to Windows (positive I’d say)
>is being able to use mime types instead of extensions, making them
>optional. Yet for hidden files it’s the other way around… you need to
>rename instead of being able to use a different kind of mark. At a first
>look, it doesn’t seem optimal for one thing… since the name is being
>used to toggle a feature / setting instead of just being that file or
>folder’s name.
>
>The real issue I’m imagining is that if you’re using a file or folder
>as part of a full path, then want to mark it as hidden later on (say you
>don’t want to see it all the time in Dolphin) its path would change. So
>if you have the location /foo/bar (where bar is a file and foo a folder)
>and you wanna make foo a hidden folder, the path would then become
>/.foo/bar and would need to be updated in any script or application
>relating to it. Not sure if the Linux path system can automatically
>translate this (ignore the . and use the old path, or the other way
>around) which would offer an advantage. Also, would this allow items
>with the same name to exist in the same folder (filename and .filename)?
>
>What are the benefits of hiding things this way, and are there
>alternative ways to mark files and folders as hidden? Note that I’m not
>trying to “make Linux be like Windows” nor mind how it works. Others
>know better why it was done this way, but I’m trying to learn why this
>option was chosen and is still used in Linux at this day.
As an alternate answer, it derives directly from Unix at its very
beginnings. Thus the ultimate answer lies in the musings of the original
creators of Unix, including Kernigan and Ritchie of “C” fame. There were
a lot more vendors of computers and OS’s back then.
Control Data Corp (CDC), Perkin-Elmer, Nixdorf, Digital Equipment Corp
(DEC), Data General, Amdahl, and others i no longer remember predate Unix.
A little later Sequent/Sequoia, Tandem, Non-Stop, Sun, Pyramid and the
boom. Note that the second group all ran Unix variants.
One interesting kicker is that Cray is still around.
See:
http://en.wikipedia.org/wiki/Computer_history
The article can be improved quite a bit easily, maybe i should chip in,
after all i was there for a lot since 1970.
?-)
On Sun, 30 Sep 2012 12:15:43 GMT, Martin Helm
<martin_helm@no-mx.forums.opensuse.org> wrote:
>Am 30.09.2012 14:08, schrieb Carlos E. R.:
>> Remember that unix pre-dates MSDos, thus some features were experimented here earlier.
>I am almost sure if UNIX where designed today instead of decades ago
>“hidden” would be an attribute (and we would have much more attributes
>and acls by default). The prefix dot notation is just backwards
>compatibility and was obviously good enough not to change it to
>something else.
Backwards compatibility to what? Multics did that differently IIRC. As
did IBM MVS, VM/CMS, Vax VMS, and CDC NOS; IIRC.
???-)
On Sun, 30 Sep 2012 19:26:01 GMT, MirceaKitsune
<MirceaKitsune@no-mx.forums.opensuse.org> wrote:
>
>Thanks for all the info, it makes more sense now. I think the . operator
>should always stay there for backward compatibility of course, but
>wouldn’t mind seeing a new form of hiding stuff as well (like a
>parameter). Still finding out what mime types are… I thought they’re
>information / flags embedded into the file as an alternative to having
>an extension.
Here is a real good start on (Multipurpose Internet Mail Extensions) MIME
types:
http://www.ietf.org/rfc/rfc2046.txt
Note that this is part two, and see what it obsoletes. Then search for
what obsoletes it.
?-)
On Sun, 30 Sep 2012 21:18:06 GMT, “Carlos E. R.”
<robin_listas@no-mx.forums.opensuse.org> wrote:
>On 2012-09-30 22:36, hcvv wrote:
>>
>> nrickert;2492152 Wrote:
>>> I’d say that is not entirely accurate. From the beginning, “file.c” was
>>> source code, “file.o” was compile but not linked object code.
>>>
>>> The operating system itself does not assign a meaning. That is left to
>>> users and applications. But that kind of use of extensions didn’t
>>> spread to the unix world - it was there from the beginning.
>> I admit that some of those “endings” (of one character only) where used
>> from the beginning and that applications (like compilers) used them. But
>> they weren’t called “extensions”.
>
>There are file browsers that look at the extensions for file types, not at the actual contents.
>For example, midnight commander. And konqueror or nautilus, I think.
Konqueror and nautilus both use “file” a small executable that reads the
first 128 bytes or so and makes “guesses” about the type. It is
astoundingly accurate, but then most binary file types announce themselves
in the first block anyway. Look at a lot of them with something like
hexedit.
?-)
On Sun, 30 Sep 2012 22:46:01 GMT, MirceaKitsune
<MirceaKitsune@no-mx.forums.opensuse.org> wrote:
>
>robin_listas;2492160 Wrote:
>>
>> No, they are strings sent from webservers and other internet services.
>>
>> Lookup the command “file”, find out how it works.
>>
>> –
>> Cheers / Saludos,
>>
>> Carlos E. R.
>> (from 12.1 x86_64 “Asparagus” at Telcontar)
>
>Ouch… I hope that doesn’t mean I need an internet connection all the
>time for Linux to recognize mime types. eg: For Dolphin to know that a
>file without an extension is an image, or a video, or what it is. That
>would be really annoying on laptops and in some cases.
It is part of the base installation for most linuxes, including openSuse,
for many years now. Not Internet dependant. Fairly small and quick to
boot.
?-)
On 2012-10-07 01:13, josephkk wrote:
> On Sun, 30 Sep 2012 12:15:43 GMT, Martin Helm <> wrote:
>
>> Am 30.09.2012 14:08, schrieb Carlos E. R.:
>>> Remember that unix pre-dates MSDos, thus some features were experimented here earlier.
>> I am almost sure if UNIX where designed today instead of decades ago
>> “hidden” would be an attribute (and we would have much more attributes
>> and acls by default). The prefix dot notation is just backwards
>> compatibility and was obviously good enough not to change it to
>> something else.
>
> Backwards compatibility to what? Multics did that differently IIRC. As
> did IBM MVS, VM/CMS, Vax VMS, and CDC NOS; IIRC.
With itself, ie unix.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On Mon, 01 Oct 2012 10:36:01 GMT, hcvv <hcvv@no-mx.forums.opensuse.org>
wrote:
>
>martin_helm;2492283 Wrote:
>> Am 01.10.2012 11:16, schrieb hcvv:
>> > Only thing you
>> > could do (but that is you, not the system) is adding a second file
>> > somewhere corresponding to every file you have, contaning it’s MIME
>> > type.
>> That would not be the case (the need to add the info in extra files),
>> if
>> our applications would just make use of the extended attributes
>> available on every linux file system.
>> >
>Code:
>--------------------
> > >
> > setfattr -n user.mime_type -v “application/xml” test.xml
> > getfattr -d test.xml
> > # file: test.xml
> > user.mime_type=“application/xml”
> >
>--------------------
>> >
>> ‘freedesktop.org - CommonExtendedAttributes’
>> (http://www.freedesktop.org/wiki/CommonExtendedAttributes)
>> defines a basic set of such extended attributes, which no application
>> I
>> know in linuxland seems to use, what a waste of time and effort,
>> instead
>> every application developer reinvents a way to store metadata in
>> extra
>> files or databases.
>> The only exception I know is SELinux which seems to use some extended
>> attributes in the security namespace.
>>
>> –
>> PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT
>> 420
>> ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.1 | HD
>> 3000
>> eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE
>> 3.5.10
>Basicaly very admirable. I am afraid that this is not enough
>standardised to be available in the same way on all types of file
>systems. Even when we limit ourselves to most mordern ones. In other
>words, we need a standard body that propagates at least a minimal
>implementataion, like POSIX did.
Ooooh. I am taking a different cut on that. IEEE published POSIX (IEEE
1003) as a common MINIMUM baseline of Unix implementations for DOD
purchasing. It is not a useful standard even for that use.
See:
http://en.wikipedia.org/wiki/POSIX
>?-)
Am 07.10.2012 01:13, schrieb josephkk:
> Backwards compatibility to what? Multics did that differently IIRC. As
> did IBM MVS, VM/CMS, Vax VMS, and CDC NOS; IIRC.
I spoke about Unix, why do you list arbitrary non-Unix systems, what’s
the point?
Linux uses the . notation for hidden files and that is backwards
compatible to the Unix systems of the time Linux was created.
Listing what non Unix system do or did is pointless since Linux was
designed explicitly as a Unix clone and not as something which is
compatible to anything else.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.5 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.2 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
josephkk wrote:
> On Sun, 30 Sep 2012 12:15:43 GMT, Martin Helm
> <martin_helm@no-mx.forums.opensuse.org> wrote:
>
>> Am 30.09.2012 14:08, schrieb Carlos E. R.:
>>> Remember that unix pre-dates MSDos, thus some features were experimented here earlier.
>> I am almost sure if UNIX where designed today instead of decades ago
>> “hidden” would be an attribute (and we would have much more attributes
>> and acls by default). The prefix dot notation is just backwards
>> compatibility and was obviously good enough not to change it to
>> something else.
>
> Backwards compatibility to what? Multics did that differently IIRC. As
> did IBM MVS, VM/CMS, Vax VMS, and CDC NOS; IIRC.
I think Martin was just saying that MSDOS and current use of .files is
just for reasons of backward compatibility with UNIX. I don’t think he
claimed that UNIX was backwards compatible with something else, but
neither did he claim that UNIX was the birthplace of .files. So it’s
origin is still unknown to us.
… as a leading character was certainly used for some control cards in
JCL in earlier operating systems, IIRC, so the idea was not completely
new. And . or $ were used for ‘here’ in many assembly languages.
josephkk wrote:
> http://en.wikipedia.org/wiki/Computer_history
>
> The article can be improved quite a bit easily, maybe i should chip in,
> after all i was there for a lot since 1970.
Yes, it seems to be full of errors and omissions.
Am 08.10.2012 13:27, schrieb Dave Howorth:
> josephkk wrote:
> > http://en.wikipedia.org/wiki/Computer_history
>>
>> The article can be improved quite a bit easily, maybe i should chip in,
>> after all i was there for a lot since 1970.
>
> Yes, it seems to be full of errors and omissions.
>
That would be great if people who had first hand experience with that
things correct what’s wrong there (I am too young, only 45) and I think
a lot of other people will appreciate that as well 
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.5 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.2 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Just a thought: Depending on “what” your trying to “hide”, and which filesystem your using there are in Linux a concept of file ownership and file permissions. Which have sepperate valus for the files owner, members of a particular “group” of users, and everybody else. The permisions control the ability to write to, read, or execute a file.
If you deny others read permission to a file, does it really matter if they can see the filename?
If you really don’t want then to even see the file name, you can prevent it by denying others the permissions to read or execute the directory in which the file resides…
So by changing the read attribute for others of the directory you can effectively hide/unhide everything in it. This way the pathname of the file doesn’t change, and it’s more completely “hidden” than simply counting on the “.filename” convention.
For more specific information try:
man chmod
man chown
If you find the syntax too confusing, you could use midnight commander (which greatly resembles the old norton commander shell{only much more powerful})
It runs inside an xterm or even on a virtual console. With it one simply selects one or more files and then selects the chmod or chown command from the menu (or type a two key shortcut) to get a check box list of attributes…
Hope this helps.
Err, I should think so. There are some files that need to be there and used (e.g. configuration files). Hence they must be readable. But you don’t want the average user to change them, or delete them (which could be achieved by making them readable only). But, as a sys admin, you also don’t want your average user(s) calling you x times a day asking you “hey there is this file that doesn’t seem to do anything, why can’t I delete it?”. So you hide it… HTH Lenwolf
And I thank God and the programers who choose to use human readable rc scripts rather than compiled configuration modules {which, I think, could be executed without being readable?} for that. Now if more of these were only well commented…
But you don’t want the average user to change them, or delete them (which could be achieved by making them readable only). But, as a sys admin, you also don’t want your average user(s) calling you x times a day asking you “hey there is this file that doesn’t seem to do anything, why can’t I delete it?”. So you hide it… HTH Lenwolf
Note: I always thought being a sys admin must be a cool job…
Do you really think of “.filename” as hidden?
And since most of the user “rc” files I’ve ever found in ~/ can be commented, wouldn’t at least some of those nuisance calls go away if you routinely inserted an explicit message to those curious enough to find the .files at the top and/or bottom of said files, or perhaps a .ReadMe.First explanation of the risks of annoying the sys admin with questions for which the answers are contained in the said .ReadMe.First file???
But when I think about some of the {many derogatory expletives deleted} lusers I used to work with, It wouldn’t surprise me if in some cases, it might it be tempting to just do something like:
# chown root /home/luser/.[a-z]* && chmod 644 /home/luser/.[a-z]*
And perhaps come up with some kind of caller ID based method to route the calls of repeat {non-executive!} offenders to voicemail…
{Snicker}
jtwdyp wrote:
> Do you really think of “.filename” as hidden?
It doesn’t really matter what us humans think. The point is that the
tools treat them as hidden. For example:
ls
is different to
ls -a
and GUIs have options to show or hide ‘hidden’ files
There’s been a lot of discussion here I can’t fully catch up on. But from what I understood, the . method is a feature that existed with Linux since the early days, and its reasons make more sense now. I’m still curious if any alternative implementations exist as well or are planned… so being hidden or shown can be a property of the file rather than a mark in the file name. Maybe either stored as meta-data on that file / folder, as a text file in the base folder containing a list of everything hidden in there, or even just a local setting of the file manager (like Dolphin). Not that I necessarily need one, but if there are other ways I’d like to know about them more thoroughly.