Talk:File system

Contents

1 Filesystems Under Microsoft Windows 2 Types of file systems 3 HFS 4 On keeping or removing the folder image (status: removed) 5 Folder represenation of a filing system 6 Secure Computing 7 File names from the perspective of persons doing normal office work 8 Old discussions 8.1 partition types

Filesystems Under Microsoft Windows

This section really needs to be cleaned up and checked. I made a few edits and clarifications but it still needs work. Article seems to assert Windows (in general) only uses FAT32 and NTFS, and derived those from FAT and HPFS. Obviously this is not true. We should also mention FAT12. Dsav 04:54, 28 Apr 2005 (UTC)

Types of file systems

The article was made inconsistent with the addition of Database file systems as a separate type.--Chealer 19:01, 2005 Feb 20 (UTC)

No- database filesystems are fundamentally different from folder-based or hierarchial filesystems- database filesystems are constructed on metadata searching and constructed on the fly. This is very different from a logical tree mapped to sectors on a disk. -- Maru Dubshinki 07:18 PM Monday, 07 March 2005

HFS

Is HFS also used on Mac OSX? It only says Mac OS, but this is vague -- the term sometimes excludes versions prior to X but could apply to both. Could someone clarify? Tuf-Kat 00:59 Apr 1, 2003 (UTC)

Currently, Mac OS X uses HFS+J (Hierarchical File-System Plus Journaling). All file-systems are case-preserving and case-insensitive (one can capitalize any way one wants, but one can not have two files in the same folder with the same name differing by capitalization and searches are case-insensitive).

1. Firstly came MFS (MacIntosh-File-System). MFS was a flat (no folders) 16-bit File-System.
2. Then came HFS (Hierarchical File-System). HFS was a 16-bit file-system with b-trees for creating folders. HFS could only handle 64 kilofiles. and if the with large file-systems, HFS wasted disk-space. HFS could only have files up to 64 kilobytes.
3. HFS+ (Hierarchical File-System Extended) is a 32-bit version of HFS. It can handle up to 4 gigafiles. It can handle files up to 4 gigabytes. The native file-system of the first three versions of Mac OS X was HFS+.
4. Starting in Mac OS X version 10.2.2, one could added a journal-file to the file-system. This journal-file contains a backup of metadata which prevents corruption of the file-system. Starting in Mac OS X version 10.3.0, HSF+J became the default file-system of Mac OS X.

:HFS+J is identical to HFS+ with an extra file, thus backwards compatible for Mac OS version 9. When Mac OS X will die, :Apple.Com  (http://Apple.Com/) will release a new file-system. Apple.Com  (http://Apple.Com/) is tight-lipped about the new file-system, but the :rumor is that the new file-system will be a 128-bit journaling RAID-based case-preserving case-insensitive metadata-rich :file-system. This is just a rumor, and rumors are a dime a dozen. --Ŭalabio 05:22, 2004 Dec 4 (UTC)

::Post Scriptum:

::I forgot to mention these because MacIntosh-Users take these for granted, but:

• The user has complete control of the names of files because filetype is in metadata stored with the files -- not in an extension of the name.
• In addition to hard links and symbolic links, one also has aliases which contain the file-ID# and its path and name. Because these ::filesystemlinks can find the file, even if one moves and renames the file. If one deletes and replaces a file, the alias can find the replacement file ::because the alias has path and filename in it. Aliases are so useful that over 90% of all filesystemlinks are aliases on MacIntoshes.  ::Aliases arrived with HFS.
• One can name files using Unicode. A filename can have up to 255-UTF-8 octets in the name.

--Ŭalabio 05:08, 2004 Dec 24 (UTC)

On keeping or removing the folder image (status: removed)

Filing systems contain folders, and on many systems fses are presented as folders themselves. "Nothing to do with FS" is a bit harsh. If you have schematics and such for fses, please bring those images in. Cases where an fs is represented with the above icon:

• Unix GUIs
  • konqueror on KDE 3.x uses this precice icon in /mnt. (that's where I copied it from, so deal)
• RISC OS uses a similar icon for:
  • SparkFS folders
  • ResourceFS

Please explain why you keep reverting it out? --Kim Bruning 10:23, 4 Apr 2004 (UTC)

A filesystem is an abstract structure of (most commonly) the magnetic polarity of sections on a disk. It has absolutely nothing to do with pictures of folders. I'm strongly considering removing it from Folder and Directory as well because it adds nothing to any of these articles, adds approximately 6kb to the page download, and it looks very ugly on 256 color displays.

I don't know why you put it in any of these articles to begin with. --Darrien 11:00, 2004 Apr 4 (UTC)

It is relevant to Folder and to Directory because a "Folder is the WIMP representation for a directory". I'm willing to bet that 99% of the world population that owns a computer will tell you that that little icon actually *is* a directory. (Whoops, no, but that's what they'll say). It's useful to remind people that they've come to the right place.

Yes and no to magnetic polarity of sections on a disk, it's actually 2 levels of abstraction higher already. First up you make a rough partitioning of the hard disk (1st level). Then when you're treating the magnetic polarities in such partitions as a bunch of 1's and 0's, how are you going to organise those 1's and 0's so you can find back what you put there?

Well, that's where filing systems come in (2nd level). Or not. Originally people thought that virtual memory would be sufficient, and this kind of thinking even seems to be making a comeback ( http://www.prevayler.org/wiki.jsp ). Alternately, instead of a simple filing system, some people propose using a database instead. I believe that some mainframe operating systems already do this, but I'm not sure which ones at the moment. In any case a fellow by the name of Hans Reiser is advocating switching to a database style of dealing with information for current operating systems.

You mean the ReiserFS, which is much like a database anyway, what with the b-trees and journalling? -- Maru Dubshinki 07:31 PM Monday, 07 March 2005

So in any case, filing systems are virtual constructs already, are somewhat controversial even(!) and they are represented by the icon we're talking about. So let's use the darn icon. Sheesh!

Did I already mention that the picture of a folder is what a filing system looks like in a common GUI? Sames goes for directories? See: KDE. I actually went into the /usr/share/kde and grabbed exactly that image. (And no that's not a copyvio, before you try that track, the image is GPL, which should be compatible with the GFDL, or someone at GNU should be shot)

Your 6Kb and 256C arguments are entirely pointless, and I don't really intend to discuss those at all. Modern browsers allow you to "turn off images" when they're not working for you, and that even goes for lynx and links.

Sorry for making this a long rant rather than a short answer, but I'm kind of exasperated! --Kim Bruning 11:38, 4 Apr 2004 (UTC)

I'll be brief: Abstraction is abstraction, your database information is pointless,

I don't understand why you would advocate the murder of someone who made two licenses incompatible, my "6Kb and 256C" arguments are perfectly valid, and finally, lynx can't display images in the first place.

You don't strike me as a particularly rational person, not to mention uninformed. If you can't understand any of the points I've made, then I would advise you to call for arbitration. --Darrien 12:17, 2004 Apr 4 (UTC)

Well, that's what's called a personal attack. Sheesh! But I think arbitration might be overkill for this particular dispute.

Okay well, on abstraction I'm trying to point out that FS is at a different abstraction layer than you suggested at first.

Your claim was that it worked directly on magnetic particles on a Hard Disk, and my claim is that it actually works on sets of bits that have been predivided into partitions.

It's an almost pedantic point, sure. The reason I made it anyway is that there is a rule that says that it is Good Design to keep abstraction layers strictly separated.

* This should give you a clue to where you might have a flaw in your thinking. (A rather large flaw, since your definition precludes ram drives and flash memory. )

* Thinking about layers of abstraction might also give you a clue as to how a folder icon might be relevant here.

You just answered why 6Kb and 256C are irrelevant by yourself in the very same sentance where you claim they are relevant.

Basically, what I'm saying is that you haven't thought things through properly on a number of levels, and it's showing in your arguments. Compared to that, I don't mind much what happens to a silly image. (But I'd prefer to keep it just the same :-) ) --Kim Bruning 12:40, 4 Apr 2004 (UTC)

I shouldn't make what might be seen as a personal attack just after blaming someone else for doing the same, so I've struck that part through. (can't simply delete because I'm in a dispute here :-( ) My apologies. --Kim Bruning 12:51, 4 Apr 2004 (UTC)

Please tell me how calling you irrational for endorsing the murder of a person who makes two licenses incompatible is a personal attack. --Darrien

We both know that he shouldn't *really* be shot. Sheesh! --Kim Bruning

Then why did you say that he should be? --Darrien

I didn't, it's just a figure of speech. Sorry if you hadn't heard it used before. :-) Let's drop this line. --Kim Bruning

Please tell me how calling you uninformed for saying that images can be "turned off" in a browser that doesn't even support images is a personal attack. --Darrien

Well, words like "uninformed" and so can often be construed as such. Hmm, QED, since I actually thought you had made a personal attack :-)

Now why would I mention lynx if I knew it didn't support images? --Kim Bruning

I don't know. That is why I considered you to be uninformed. --Darrien

I give up. Let's skip the lynx line of reasoning. --Kim Bruning

Go back and reread my first message, paying particular attention to the "most commonly" part. --Darrien

Ahhh, yup, you did say most commonly. Still what I said about levels of abstraction holds true. Perhaps we'll find out we're in violent agreement with each other in a minute. Let's see. --Kim Bruning

I never said anything about the level of abstraction. A file system is an abstraction regardless of what level of abstracion it uses. You are trying to throw a red herring into this discussion. Please answer only the relevant points. --Darrien

Alright, well, a folder is also a level of abstraction, right overtop of a file system in fact, and is definately very strongly related to it. --Kim Bruning

Exactly my point. A folder is not part of a file system. It can be overtop, but there are also flat file systems with no concept of folders or directories. --Darrien

The flattest possible filesystem can still be mapped to a folder representation. (see below, else we're going to get a lot of indentation :-) ) --Kim Bruning

Explain how the 256 color and 6kb is irrelevant. If you knew anything about logic or proper debate, you would know that the burden of proof is on the accuser. "You just answered why 6Kb and 256C are irrelevant by yourself" is not a sufficient rebuttal. --Darrien

Well, you basically said "This picture adds 6Kb to a page download, and doesn't look right in 256 colors, besides, lynx doesn't support images at all, are you uninformed?" Ahuh, okay, right... --Kim Bruning

When I introduced the 256 color and 6kb arguments, I made no mention of lynx. This is the point you should have rebutted. The sentence I believe you are refering to, separated 256 colors and 6kb from lynx with a comma, and the word "finally". Which should obviously make them separate points. --Darrien

Alright Alright. Let's drop lynx for now. In any case, if you have trouble downloading images, you can just turn off images in your browser, so that's not really a problem. And image sizes and colordepths etc. are really very pedantic indeed. Can we just drop it and concentrate on your main line of reasoning? --Kim Bruning

Folder represenation of a filing system

Note that I'm differentiating between "folder" (a representation of an FS or Directory) and "directory" (a special file or area that contains references to files, directories, and/or other special files or areas) here.

Any filing system with an appropriate interface can be accessed by a filing system viewer, and be represented in this way. A folder is simply a representation or symbol that stands for either a filing system, or -if the FS supports it- a (sub)directory in that filing system.

I can draw a folder on a piece of paper and say it represents my filing system, even if there is no actual UI on the machine involved in the process. Actually I probably won't even need to explain. If I were to take a piece of paper and draw a tree of folders (using the folder symbol), a random person these days will probably be able to read my diagram.

Since the symbol actually represents a filing system, it should be here. --Kim Bruning 16:29, 4 Apr 2004 (UTC)

We obviously aren't going to come to an agreement. You should call for arbitration. --Darrien 07:32, 2004 Apr 5 (UTC)

Arbitration will just force the issue to a resolution, but won't really actually do much else, we'd simply have the same arguments, but then in arbitration. I regret typing my first rant so quickly now, so it looked less coherent than it could have been.

Let's try a third avenue and compromise here: do you have a proposal for different illustrations for each of folder, directory, and filing system? And can you provide those? That'd be constructive.

• folder : folder.png folder_cyan.png is an actual folder, so that's hard to dispute. But go ahead if you have a better one.
• directory : well, a folder is a representation for a dir, but if you can actually find some nice schematic for how directories are set up on some fs, that'd be excellent.
• file system : Well, a picture is better than none IMHO. But if you have schematics for FS organisation. (Maybe you can draw some for dos, or use some off of the reiserfs site if I recall correctly) then replace the image with something you have.

So my proposal is this:

I recognize that you disagree with folder.png Folder_cyan.png on some of those pages. As soon as you have a better image to replace it on each, replace it then. I won't disagree with you.

Remember it's often better to leave something that's just about right on wikipedia, than to delete everything that is remotely slightly off.

Try to improve on what's there. Don't simply delete. :-) --Kim Bruning 09:33, 5 Apr 2004 (UTC)

I am through discussing this.

After your outright lies on my talk page, and throwing in Folder.png when this entire discussion centers on Folder_cyan.png, I strongly suspect that you are in this discusion only to stir up trouble. --Darrien

Sorry, that was just a typo. Sheesh! Corrected. I'm surprised folder.png actually exists. I guess that's the other image on that page eh?

re: Lies , um, you do realize that the page history is recorded right? --Kim Bruning 12:32, 5 Apr 2004 (UTC)

If you don't drop this, then we will be forced call for arbitration. It's the only way this dispute will be resolved. Please tell me if you are going to concede or if you wish to call for arbitration. --Darrien 11:31, 2004 Apr 5 (UTC)

Well, usually it's a good idea to just ask a third wikipedian to take a look, I'll ask for a wise person who happens to be a sysop to drop by. --Kim Bruning 12:32, 5 Apr 2004 (UTC)

• For what it's worth (and maybe I'll regret getting into the middle of this), I can't honestly see what a stylised icon of a folder, taken from a fairly obscure desktop (for most people), adds to an article about "File Systems." The image is already used (more appropriately) in the Folder and Directory articles... both of these articles are linked to from "File Systems." It doesn't really fit here, and it certainly isn't worth fighting over. Perhaps one of you can find an image showing how inodes link under an Ext2-style FS, or how the old DOS FAT system worked. --Motor 18:51, 5 Apr 2004 (UTC)

• • Well, afaict he wanted to remove the image from both those as well. I agree the icon is less useful here, I just tossed it in so that there's at least *some* illustration, and imho it was defensible to do so at the time. :-)

  I agree we should have FS organisation diagrammes. I'd suggest at some point to have or link to discussions on DOS FAT, EXT2 , and maybe ReiserFS (examples of fses from very roughly the 80's, 90's and 00's for which good documentation exists or can be obtained.)

  Hmm, looks like it's almost time for me to set up a TODO list :-P --Kim Bruning 09:59, 6 Apr 2004 (UTC)

---

And here I am. Well.....this seems like a tempest in a teapot to me (note: not an actual storm, which of course could not physically appear in a small porcelain container), but it seems to have raised hackles. I would suggest that the picture should stay, but that Darrien should add some language to the article and/or caption explaining why it's not actually a file system. When dealing with computers, every viewable image is an abstraction of sorts. I think it would actually be quite instructive if Darrien added something like the following (and I don't know huge amounts concerning file systems, so I may be incorrect in this -- please don't yell at me if I am, but do inform me): "The image at right is an icon commonly used in Windows operating systems to graphically represent the directory/folder structure of the file system used in Windows. For most computer users worldwide, this image is synonymous with file systems and managing files, although it is in fact representative only of the particular file system used in Windows." That paragraph is inelegant and in need of some fixing, but I hope you see my point. When an image is misleading, Darrien, I'd say nine times out of ten it's best to explain it rather than cut it. And Kim, Darrien is very new here, judging from User Contributions -- I think perhaps there could have been a slightly friendlier approach to this dispute which might have stopped short of the above argument.

That's my attempt at frontier justice. I think you can both have part of what you want here. And Darrien, I have no idea how you know about arbitration after being here a week, but you obviously haven't learned yet that arbitration is not used to settle disputes like this. A few old hands like myself are dragged in to try and make everyone be nice to each other and compromise, and if that doesn't work, the community is invited to discuss things and then cast their vote for the best possible solution. This takes weeks to accomplish, and so it's easier for everyone if we settle things amicably. I encourage you to try it. --Jwrosenzweig 17:46, 5 Apr 2004 (UTC)

Why do you say that I've been here for only a week? My first contribution was in June of 2003 and I have been a reader for longer than that.

Arbitration has been used for thousands of years to resolve disputes. Why do you think that I shouldn't know about methods of settling disputes?

I explained why I removed the image in my commit summary, it's unneccesary. Having a picture of a folder on a page about file systems is like having a picture of a paintbrush on a page about color. Yes, there is a slight relationship between them, but not enough to warrant its inclusion.

Also, nothing personal, but if you, by your own admission, don't have much knowlege of what a file system is, then perhaps you shouldn't be arbitrating this discussion. --Darrien 14:35, 2004 Apr 6 (UTC)

I'm afraid that Darrien is right. The image adds nothing whatever to the article, except distraction. If it were meaningful, sure. But it bears no relationship to the topic, and serves only to imply that a file system is something to do with cutsie pictures on your screen. Strikes me as a classic case of Powerpointitis: there is nothing to illustrate, so let's have an illustration anyway. But why a folder? Folders are pretty boring, after all. Wouldn't a nice fluffy kitten look better? --Tannin 14:45, 6 Apr 2004 (UTC)

• How about actual illustrations to do with how an FS is organised? (see above) :-) --Kim Bruning 16:51, 6 Apr 2004 (UTC)
  • In fact: see here: http://www.namesys.com/v4/v4.html , we'd have to ask politely, and it's a slightly off-the-norm FS. I knew that page existed already. I wonder if there's other pages like that. --Kim Bruning 17:08, 6 Apr 2004 (UTC)
  • Here's ext2 : http://www.tldp.org/LDP/tlk/fs/filesystem.html --Kim Bruning 17:11, 6 Apr 2004 (UTC)
  • No images, but something might be made, based on http://www.tldp.org/HOWTO/Filesystems-HOWTO.html#toc2 --Kim Bruning 17:20, 6 Apr 2004 (UTC)
  • Existing illustrations for FAT (may require permission): http://students.cs.byu.edu/~cs345ta/labs/fall03_specs/lab_fat_help.htm --Kim Bruning 17:23, 6 Apr 2004 (UTC)

Okay, that covers all the bases. It's on my todo list, unless one of you wise guys beats me to it ;-)

have a nice day! --Kim Bruning 17:23, 6 Apr 2004 (UTC)

---

Secure Computing

Secure computing explicitly discusses Capabilities versus ACLs. I think this is going to be rather straightforward. :-) --Kim Bruning 11:09, 27 Jun 2004 (UTC)

Access control list also states that there is some difficulty with them, and reccomends use of Capabilities instead. So hmm, apparently that's the consensus on wikipedia then. An existing consensus can always be wrong of course. If you diagree with what's written there, I suggest you take it up with the writers of access control list and secure computing first, to prevent duplication of effort.

Have a nice day! --Kim Bruning 11:37, 27 Jun 2004 (UTC)

The paragraph as it now stands is acceptable—or at least more so than my desire to argue it. I would prefer it to move out of the introduction and into its own section discussing ACLs and other security mechanisms as applied specifically to filesystems, however. (Honestly, this article in general could do with a complete rewrite...) --—Lady Lysiŋe Ikiŋsile | Talk 14:03, 2004 Jun 27 (UTC)

File names from the perspective of persons doing normal office work

A search for an article on file names is redirected here to the file system. Should there not be an article for file names per se, to cover the customs and practices and the art and science of naming files from the perspective of persons doing normal office work, and not from the very limited perspective of computer science? --AlainV 21:02, 2 Sep 2004 (UTC)

Don't think so- this is an article about the very specialized and restricted field of logically storing and organizing data on physical computer-read media, and the abstract structures they embody. You might want to look into more general areas like the Dewey decimal system or stuff like that. -- Maru Dubshinki 07:50 PM Monday, 07 March 2005

Old discussions

partition types

Programs that are used to partition a disk drive (fdisk et al.) sets a partition type, e.g.,

0C for FAT32 82 for Linux swap 83 for EXT2 or EXT3 ( Linux )

(see http://www.symantec.com/techsupp/primus/id4279.html for a long list)

There are perhaps some 50-100 allocated numbers. Where does these numbers come from? Where is the standard?

What is the origin of the standard? IBM PC, IDE, ATA, Microsoft or what? Does SCSI drives on a PC use the name partition type number standard? SCSI drives on a Cray?

-- DavidCary 03:41, 23 May 2004 (UTC) and hif dec 24 2003.

Those are good questions for the page about partitions.--Chealer 19:01, 2005 Feb 20 (UTC)