Jump to content

Talk:File system/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

NTFS and posix

you asumed {{no}} at all the posix question and link to a part of the page saying that they are acessible from SFU that is corect but asume a certain design that is not true theses options ARE THERE BY DEFAULT!!! but not acessible trough win32 they can be acessed trough SFU but not only...

  • windows NT(not 2000) has a unix layer
  • mabe linux or others os that are compatible with NTFS

Information about Reiser and ext (and other FSs) not storing creation timestamp?

The tables show that the Reiser and ext file systems (and others) do not store file creation timestamps. I believe this is not true. A recent discussion on a Linux mailing list turned up the following:

any file on any filesystem has a creation date and time and if necessary, you can "touch file" so it updates the date and time to now.

  1. vi abcd
  2. ls -l abcd

-rw-r--r-- 1 root root 9 2005-08-19 12:39 abcd

  1. touch abcd
  2. ls -l abcd

-rw-r--r-- 1 root root 9 2005-08-19 12:45 abcd

Any comments or thoughts?

Yes,

Creation time is not supported by the standard infrastructure unix/linux supplies for file manipulation. Without resorting to non-standard extensions you will not specifically find a permanent "creation" time for a file.

This Unix FAQ states:

3.1) How do I find the creation time of a file?

You can't - it isn't stored anywhere. Files have a last-modified
time (shown by "ls -l"), a last-accessed time (shown by "ls -lu")
and an inode change time (shown by "ls -lc"). The latter is often
referred to as the "creation time" - even in some man pages -
but that's wrong; it's also set by such operations as mv, ln,
chmod, chown and chgrp.
The man page for "stat(2)" discusses this.

The aforementioned mailing list discussion appears to have confused the modification time with a creation time. -- Guy Harris 00:44, 22 September 2005 (UTC)

ReiserFS

ReiserFS seems to support Access Control Lists acording to http://elibrary.fultus.com/technical/index.jsp?topic=/com.fultus.suse.guides/guides/9_0/suselinux-adminguide_en/node27.html "Access Control Lists are a feature of the Linux kernel and are currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS." If anyone knows if this is correct plase change it in the table. --Cspurrier 19:01, 1 Oct 2004 (UTC)

Suse includes the "widely-used add-on" (mentioned in the footnode) that adds the extended attribute support, enabling this feature in ReiserFS in that distro. But if you have reason to believe any part of the table is wrong please do go ahead and fix it. Saucepan 19:19, 1 Oct 2004 (UTC)
ReiserFS does not have native support for ACLs. The ACLs are just stored in a file called "xattr" in whichever directory. BTW As far as I know, neither do ext2 and ext3, they both use the same addon don't they? AlistairMcMillan 19:28, 1 Oct 2004 (UTC)
The bestbits page seemed to suggest that the ACL support was in the 2.4 and 2.6 kernels for ext2 and ext3, but required the extended-attributes add-on for ReiserFS. Either way, though, I guess we should decide where we want to draw the line between a standard, interoperable on-disk feature of a filesystem vs. a software enhancement present on a particular OS.
How about the following test: Admin Alvin removes a drive formatted with Filesystem X and sends it to Admin Betty in another city. Alvin doesn't know whether Betty is running a different implementation of the filesystem software on a different OS, and Betty is only told the name of the filesystem. Would Alvin reasonably expect that Feature Y would work when Betty mounts the drive? (Where "work" would mean the feature was operational, the information was preserved and recognized, and/or the security policies were being enforced, depending on the feature.) If so, then Feature Y is pretty clearly supported by Filesystem X. If not, then other factors might need to be considered. What do you think? Saucepan 21:02, 1 Oct 2004 (UTC)
I think you may be misreading the bestbits page. This site hosts extended attribute and access control list kernel patches for the 2.4 kernel series (ext2, ext3, nfs) and for the 2.6 kernel series (nfs). The 2.6 kernel already includes support for ext2, ext3, jfs and xfs. and Additional file system EA and ACL patches are available elsewhere:. Additional file systems being JFS, XFS and ReiserFS. AlistairMcMillan 21:36, 1 Oct 2004 (UTC)
Apologies if I'm just unusally dense today but I'm not seeing how this differs from my summary of the situation. What am I missing? Saucepan
You said that ACL support is in the kernel but ReiserFS needs the add-on. However ACL support in the 2.4 and 2.6 kernels uses the "extended-attributes add-on" in the same way that ReiserFS does. You can even see Ted Ts'o's original submission of earlier versions of the patches for the 2.6 kernel here. AlistairMcMillan 22:33, 1 Oct 2004 (UTC)
BTW By your test, then ACLs are not part of ReiserFS, ext2 or ext3. Not all distros have ACL support compiled in. I have very little understanding of XFS and JFS so I'll leave them to someone else. AlistairMcMillan 21:45, 1 Oct 2004 (UTC)
The proposed test can prove that a feature is supported, but can't conclusively rule that it isn't (since it might be optional, require some configuration, or have other factors that need to be considered). OSX UFS has some grey-area features like this as well, if I remember correctly (like resource forks). Saucepan 21:58, 1 Oct 2004 (UTC)
Looking around for specifics I found this. Someone in the exact situation you described. Trying to mount an ext3+acl parition in Fedora Core 1 and having problems because the default kernel in FC1 doesn't support the ACL extensions. AlistairMcMillan 23:41, 1 Oct 2004 (UTC)

FAT32 data

It's difficult to find definitive information about FAT32 file and volume size limitations since they've been increasing with seemingly every Windows version/service pack, leading me to believe that many of these limits were imposed by the OS rather than being limitations of the on-disk format. The FAT32 maximum path name length of 260 UCS-2 characters is from [1], but seems suspiciously low to me. If you find any of the info fishy then feel free to change it to "?" and leave a note here. Saucepan 07:12, 23 Sep 2004 (UTC)

IIRC, that 260-character filename limit is listed that way in MSDN. It might still be the consequence of an OS limit, but I wouldn't want to use a longer file name on a FAT32 partition anyway, which makes it a de-facto limitation.
I'm not sure that this kind of limitation is very important anymore. At 260 characters (be it maximum pathname length or filename length), people and programs tend to assume infinite size and will report back the error from the file system.
I'd list only lengths below 100 or so - these are indeed practical limitations. Distinguishing between the ability to have 100 or 1000 characters in a name is more a specialist question, and Wikipedia can't do that because then a lot more details would have to be covered.

Joachim Durchholz <jo@durchholz.org>

NTFS and Timestamps

Question: I know that NTFS internally uses GMT/UTC for all timestamps, while most other filesystems supported by Windows use localtime. I know that most Unix-like platforms do their internal timekeeping in UTC/GMT. I do not know how MacOS and other platforms handle these issues. Somebody who does know, please edit this table accordingly, because particularly at times of the year when millions of people have recently switched between summer and winter local time, this can make ambiguities when files are copied between partitions that use universal time and partitions that use local time.

MacOS 9 and earlier operate on localtime, MacOS X uses GMT, HFS uses localtime, and HFS+ uses GMT. From HFS Plus Volume Format, 

Google is your friend. --Martin Rudat(T|@|C) 09:11, 18 February 2006 (UTC)

HFS+ POSIX permissions

One of the design goals of HFS+ was POSIX compliance. Mac OS X requires POSIX permissions, and it runs best on HFS+ volumes. Indeed, Mac OS X lets you set permissions just as any other *nix system does. Can anyone disprove this? (The Apple developer doc linked from HFS Plus is over my head. I'm not a coder, heh.) -- tooki 17:34, 25 Nov 2004 (UTC)

I don't think POSIX compliance was a priority when HFS+ was introduced with OS 8.1. Not that they didn't add case sensitivity (a POSIX requirement) to the filesystem until Mac OS 10.3. However you are right that for Mac OS X (and possibly before) they did add unix permissions. See Wilfredo Sanchez excellent USENIX 2000 paper for more detail: http://www.wsanchez.net/papers/USENIX_2000/ AlistairMcMillan 00:28, 26 Nov 2004 (UTC)
I don't remember where I read it, but I do believe that POSIX compliance was one of the design goals, way back before 8.1. I know that HFS+ has had permissions and long filename support from day 1. Mac OS, however, did not. The case-sensitivity (like long filename and permissions support) is really more of an implementation issue, isn't it? Wouldn't the host OS be responsible for its implementation of the FS code? -- tooki 17:10, 26 Nov 2004 (UTC)

Remember that (as of this writing - 10.4.4) HFS+ is case preserving only:
$ touch a A
$ ls
a

That's "case-insensitive". "Case-preserving" would be:

$ touch a
$ ls
a
$ rm a
$ touch A
$ ls
A

As of 10.3, HFS+ (or, to be technically accurate, HFSX) file systems can be case-insensitive and case-preserving or case-sensitive and case-preserving. By default, it's case-insensitive, so the "Macintosh HD" volume on a machine shipped from Apple will be case-insensitive, but you can make new file systems that are case-sensitive, at least on OS X Server. (You might have to use the diskutil command on the non-server version, as per Mac OS X Server Command-Line Administration For Version 10.3 or Later; I don't know whether Apple would support that.)
It might not be possible to freshly install OS X on a case-sensitive root volume. The 10.3 server installer, at least, won't let you install on a case-sensitive volume, according to a knowledge base article on the Apple Web site, and the client installer might not even let you format the volume as case-sensitive. Guy Harris 10:53, 1 February 2006 (UTC)
I have not tested, but in the Installer, you can launch Disk Utility to format the volume as HFSX (case-sensitive) and then the installar should work.
Also you can format volumes as HFSX with Disk Utility in an installed system.
—Claunia 14:46, 1 February 2006 (UTC)
The 10.4 install DVD will indeed quite cheerfuly format and install upon a HFSX filesystem. --Martin Rudat(T|@|C) 09:17, 18 February 2006 (UTC)

Journal types

Would it be worth mentioning in the table whether the file system supports journaling all data or just metadata? --Yamla 00:18, 2004 Dec 15 (UTC)

I added it --80.99.61.48 02:53, 11 Apr 2005 (UTC)

Mac os X

I'm a bit confused by the table -- my 10.3 mac reports HFS+ as its filesystem, not UFS -- Tarquin 15:43, 24 Jan 2005 (UTC)

You can choose between them when formatting a disk, see /Applications/Utilities/Disk Utility

NSS

Novell is tight-lipped when it comes to actual descriptions of the features of their NSS filesystem. I had to dig around on quite a few different sites to get the data I did. Anyone with corrections or additions is welcome to add. Thanks, MARQUIS111 Feb 1, 2005 11:00am EST

The Novel Open Entrerpise Server for Linux beta comes with a linux port of NSS deliver in source form and under GPL. The code is completely unreadable though, I doubt it'll help you a lot ;-)

I've tried to find a good definition of Block Journaling but cannot find a definitive answer. I assume it means dat both data and metadata are journaled. If that's the case then NSS does not support Block Journaling (current status is '?'). JoetjeF 21:56, 26 August 2005 (UTC)

Novell's NWConnection magazine has an article dicussing NSS features and technology specifically on Linux at: http://www.novell.com/connectionmagazine/2005/02/tech_talk_2.html

A snippet of what they say:

Novell Storage Services brings to Linux a load of capabilities that other Linux file systems simply do not have—too many features to discuss adequately in this article. Here is a brief look at some of the other capabilities you will find only in Novell Storage Services:

Novell Storage Services efficiently manages files identified by many different namespaces. Like the traditional Novell file system, Novell Storage Services offers native support for Unicode and supports multiple namespaces, namely UNIX (case sensitive), 8.3 DOS (case insensitive), Windows Long (case insensitive) and Macintosh (case insensitive) namespaces. The name-mangling algorithm that Novell Storage Services uses efficiently manages and uniquely identifies millions of files with similar long names in a directory. In contrast, Linux (and other) file systems begin to slow considerably when managing more than only 5,000 files in a subdirectory.

Novell Storage Services enables you to set space restrictions on directories. Like Linux and other file systems, Novell Storage Services enables you to limit the amount of space that a single user can consume in a volume. Unlike other file systems, Novell Storage Services also enables you to limit the amount of data a directory or subdirectory can hold—regardless of who creates that data.

Novell Storage Services offers built-in data shredding capabilities. Novell Storage Services enables you to set the Data Shredding attribute for Novell Storage Services volumes. When you do, you indicate that the system should apply data shredding to files deleted or purged from this volume. Data shredding hides deleted and purged files by overwriting them with random patterns of hexadecimal characters. Data shredding really erases deleted and purged files, making it impossible for unauthorized users to use a disk editor to access them. This data-shredding tool supports as many as seven data shred patterns over deleted data which meets U.S. government requirements. While other file systems offer add-on features to allow for data shredding, no other file system has this capability built in.

Novell Storage Services tracks and logs files and their metadata to the Event File List. Using the Event File List, Novell Storage Services can report to information life-cycle applications about the usage of and changes in the file system under normal operations. The Event File List is the basis for Novell's File Archive and Versioning feature, currently available in Novell Open Enterprise Server for NetWare 6.5 and promised for a later version of Novell Open Enterprise Server for Linux. The File Archive and Versioning feature enables users to restore specific versions of closed or deleted files.

By Nadeem Ahmad and Abdul Majid Khan

Mac OS X UFS

I have a hunch that Mac OS X UFS is not meaningfully different from the Berkeley UFS from which it is directly derived; viz., the port of TrustedBSD to Darwin.

Not hugely so, as far as I know. Is its UFS significantly more interesting than {SunOS 4.x's, SunOS 5.x's, HP-UX's, etc.}? -- Guy Harris 01:08, 22 September 2005 (UTC)

Also, UFS is a misnomer. I know FreeBSD calls their filesystem UFS, but it is the same as FFS (The Berkeley Fast File System by McKusick). It's explained in detail in the Linux file system HOWTO. --80.99.61.48 02:55, 11 Apr 2005 (UTC)

Unfortunately, there is a lot of confusion around this. Here is the history as I saw it. The original Berkeley file system was called "FFS", but on most BSD systems of the time there was only one file system implementation so it didn't really matter what it was called. (I believe the early names are simply the names of the subdirectories in the kernel source code.) Around the time of 4.4BSD, Margo Seltzer was doing her Ph.D. at Berkeley on a log-structured filesystem. Seltzer's work motivated the separation of the filesystem code into distinct "storage management" and "Unix semantics" modules. The semantics module, which was the same in both McKusick's and Seltzer's respective work, became "UFS" (directory /sys/ufs/ufs), and the name "FFS" was attached to the remaining code implementing McKusick's storage manager (/sys/ufs/ffs). Seltzer's work then became "LFS" (/sys/ufs/lfs), and is still present in some of the *BSDs. Unfortunately, the name games caused a lot of confusion and not all of the utilities and configuration files were updated in the same way, so that 4.4BSD as released called UFS+FFS "ufs" and UFS+LFS "lfs". In FreeBSD we dropped LFS early on (because it did not work and did not show much promise in motivating developers to fix it) but because of the name confusion, UFS+FFS was subsumed under the general rubric of UFS. (It didn't help that several other OSes called their own versions of FFS "UFS" as well.) 18.26.0.18 07:05, 17 Apr 2005 (UTC)

I think the first "other OS" to call their FFS "UFS" was SunOS, perhaps all the way back to SunOS 2.x a/k/a "Sun UNIX 4.2BSD Release 2.0" or whatever it was called; that was the first SunOS to have a VFS layer into which file systems could plug (as it was the first SunOS to have more than one file system to plug into it, as it had NFS), and so FFS was dubbed the "UNIX File System". -- Guy Harris 01:08, 22 September 2005 (UTC)

This history (UFS, FFS, LFS) sounds right. However, a clear distinction needs to be made between historical FFS and modern UFS, because there are many optimization features that were in FFS that are obsolete and have been removed from UFS. While FFS and UFS are substantially similar, the two are not the same, and FFS is as good a label as any to distinguish the two. Unfortunately, there are many (incompatible!) flavors of modern UFS, and the only label we have to distinguish them is the name of the vendor that mangled them. --ssd 14:56, 6 January 2006 (UTC)
Well, it sounds right for BSD, at least. For other at least some OSes, the history I gave is correct, even if the BSD people adopted the name "UFS" from the notion that the UFS layer is the layer that provides the UNIX semantics not already provided by the storage management layer.
So what are the optimization features removed from UFS? And from which "UFS" were those optimization features removed, and was that done at the exact same time that the file system acquired the name "UFS"? If not, that sounds more like a "Berkeley Fast File System history" item than a "distinction between FFS and UFS" item.
For that matter, were those features in the on-disk data structure (which at least some have argued that this page should discuss, with details of particular implementations listed in footnotes; I express no opinion here either for or against that argument) or in the implementation? Guy Harris 22:58, 6 January 2006 (UTC)

Page is getting too big?

I noticed with the last change I saved, that there was a nastygram about the page being ~31k in size, and that something should be done to pare it down before it hits 32k. Should we split the page into currently-used and not-so-currently used filesystems?

Sample list would look like this (not all-inclusive):

Common file systems http://en.wikipedia.com/File_system_comparison

  • NTFS
  • ext2 and 3
  • Reiser 3 and 4
  • NSS
  • FAT32
  • OS X UFS
Rem: HFS+ is much more commonly used on OS X than UFS!

Not-so-common file systems http://en.wikipedia.com/Not_So_Common_File_system_comparison (I'm only semi-joking)

  • HPFS
  • NWFS
  • ODS5
  • BeFS
  • FAT12 (floppy use==current, hd use==not current)

I'll probably get shot down for this, but Wikipedia is the one who is complaining about the page size.

Thanks

MARQUIS111, Feb 23, 2005, 12:34pm EST

  • No. Split it by topic, not by filesystem. (The points to split the table by rows are pretty obvious, since it is split at those points already. ☺) We already have a split by columns, effectively, in the individual filesystem articles. What is important about this article is the rows. Uncle G 00:16, 2005 Feb 24 (UTC)
  • Having said that, there are a couple of rows that I have my doubts about, that we could potentially eliminate, to keep the table size down. There's only one filesystem for which maximum pathname length applies, for example, and I suspect that even that is only because of a misunderstanding. Similarly, as pointed out before, there's some doubt about Mac OS X UFS actually having a separate identity of its own, which could be addressed. Uncle G 00:16, 2005 Feb 24 (UTC)
  • Finally: Consider putting the table into a section and using section editing to edit the table by itself. Uncle G 00:16, 2005 Feb 24 (UTC)
That warning exists because some very old browsers are not able to deal with pages than 32 kilobytes. Given that the front pages of many major sites (including the English Wikipedia, Google News, and Excite) are already larger than this, I think it's a really nonsensical warning.
—Ghakko 15:54, 12 Jun 2005 (UTC)

Directory entry limitations

Under (for example) ext3, is it really legal to have a directory entry containing "/"? How would such a file be accessed? (For that matter, how is such a file accessed when found on a VFAT or ISO9660 filesystem?) Perhaps a note describing additional limitations (perhaps imposed by the operating system) is worth mentioning? --Andrew 20:25, Apr 15, 2005 (UTC)

  • It might also be worth mentioning the filename restrictions imposed by Windows for DOS compatibility (even in Windows NT on NTFS): "con", "nul", "lpt1" and others. 217.23.167.50 11:00, 4 May 2005 (UTC)
The Linux VFS layer forbids the use of the "/" and "\0" (null) characters in filenames. Anything else is fair game.
The filesystem drivers themselves may impose additional limitations. "vfat", for example, will not allow MSDOS path metacharacters like ":", "\" and "*".
—Ghakko 15:48, 12 Jun 2005 (UTC)


There should be more columns in the Limits table (or another table) for things like max # of sub-directories in a directory, max # of files in a directory, max depth of sub-directories, max # of files, max # of directories, and others. Also, it'd be nice to know if a limit is a tuneable parameter that can be increased or is the physical maximum. Also, don't you think that only documenting the file system limits and not driver limits is somewhat moot? Seems to me it'd be more useful to include driver/OS limits that effectively reduce the physical limits for the end user. --216.21.215.250 22:17, 1 March 2006 (UTC)

Benchmarks

Would anyone like to volunteer benchmarks for the Linux filesystems? A table containing average mongo/fsx/bonnie run times on the same system might be helpful.

—Ghakko 15:48, 12 Jun 2005 (UTC)
hhm well the problem is do we have many small files or a few large files ? benchmark results will vary widely depending upon the file size, read/write, speed of media, file count, file fragments, % of disk space left, size of disk, and so on and so forth. Anyway if you come up with a standard way of doing it leave a note on my talk page and i will see if i can find the time to write a perl script to benchmark it. --2mcm 23:54, 17 Jun 2005 (UTC)
It won't fit in wikipedia but it is perfect fot external wiki
create the article on the external wiki and add a link to it on the wikipedia page
http://techcompare.wikia.com/wiki/Index is a wiki where this content would fit
if you know any other wiki just tel me(in my talk page)
00 tux 00:21, 5 May 2006 (UTC)

HPFS

Are you sure that HPFS does not have Last entry change timestamp? I see timestamps for last change, creation and last access. --Error 23:35, 12 Jun 2005 (UTC)

  • Probably. "Last entry change timestamp" was someone's confused rewording of "inode change timestamp"; POSIX calls this "status change time" which is hardly any better. The important distinction is that this is a metadata timestamp, not a data timestamp. 121a0012 02:05, Jun 15, 2005 (UTC)
    • Aha. HPFS does not track Extended Attribute change, AFAIK. --Error 00:40, 18 Jun 2005 (UTC)
      • In HPFS terminology, this would be "f-node change". Uncle G 02:43, 2005 Jun 18 (UTC)

Block suballocation vs. block fragmentation

I just added the "block fragmentation" column, but it occurred to me that this may be what the editor who added "block suballocation" meant but didn't explain very well. The block fragmentation policy implemented in all FFS derivatives works like this:

  • Data blocks are either full blocks or fragments.
  • Only the last block of a file may be a fragment.
  • The ratio of block size to fragment size is set at initialization, and is a property of the entire filesystem (this distinguishes fragmentation from variable block size).
121a0012 05:12, Jun 23, 2005 (UTC)
    • Block suballocation is (currently) a Netware NWFS-only feature, whereby the wasted space at the end of the filesystem block, typically 64k, can be subdivided into smaller blocks, typically 512B to 8KB, which can be used for other files. Sounds a lot like block fragmentation, but it has a Novell-only twist. MARQUIS111

Be careful with the use of the term fragmentation as it is badly overused. Even fsck in FFS used both meanings. I prefer block suballocation over block fragmentation, as it is less ambiguous. Allocation fragmentation could be expressed as either internal fragmentation (when a file is scattered) or external fragmentation (when the files in a directory are scattered). BSD handles all three. Linux does all but suballocation (last I checked). NTFS does none of them, but has a defragmentter that fixes internal fragmentation while making external fragmentation worse. --ssd 15:06, 6 January 2006 (UTC)

Layout policies

It would be nice if the layout table actually said something about the layout policies of individual filesystems. In order to do so, it would be necessary to develop a succinct vocabulary to characterize the salient policies of each. There are two major axes we want to characterize: how much does the layout algorithm know about the physical layout of the disk (geometry), and how does the layout algorithm decide where to put related objects.

Geometry terms: oblivious (FS takes no account of geometry; disk is just an array of sectors), rotational geometry (FS uses classical cylinder/head/sector layout rigidly), zone geometry (FS uses information about modern ZBR disk layouts), zoned oblivious (FS does not use C/H/S layout but divides disk into a fixed number of zones or groups with the assumption that accesses within a zone are faster)

Layout terms: first fit, next fit, interleave (models platter rotation to put next block under read head at "right" time), append-only

Additional policies: directory preference (put files close to directories referencing them), zone preference (put related things in same zone), non-overwriting (always allocates new block for updates)

Examples:

  • FAT: oblivious, first fit (older implementations) or next fit (newer implementations)
  • FFS: rotational geometry, interleave, zone preference
  • UFS derivatives (including ext2): zoned oblivious, next fit, zone preference, directory preference
  • UFS/LFS: oblivious, append-only, non-overwriting
  • JFS (AIX implementation): zone geometry, zone preference
  • ZFS: ???, non-overwriting
121a0012 05:40, Jun 23, 2005 (UTC)
I could be wrong but aren't some of these OS/file system implementation specific rather then file system specific? Perhaps there are recommendations in the file system spec (if one exists) but I think for some of them, it's up to the OS/file system driver/implementation. Surely a file system implementation could put the files next to the directories or not, it wouldn't matter, it would still be understood and arguably completely legal and in many cases I suspect may not even be corrected by another implementation (even the 'official' implementation). Similarly with other policies and I suspect layout terms as well (even though I don't completely understand this). Even geometry terms I'm not sure whether it's file system specific. Perhaps in some cases but it doesn't have to be?
BTW, I believe some Windows defraggers for NTFS and FAT do in fact practice directory preference (not sure about MS defrag)
60.234.141.76 17:22, 17 September 2005 (UTC)

file systems before 1980

The article currently gives the incorrect impression that filesystems were invented in 1980.

While not every operating system includes a file system, I suspect that at least *some* of the pre-1980 operating systems included a file system:

(I've seen mainframe computers with their huge disk packs -- Early IBM disk storage -- did any of them have a file system ? Or did applications always directly write to cylinder,head,sector locations ?)

--DavidCary 30 June 2005 06:22 (UTC)

Even CTSS had a filesystem of a sort (at a level of functionality which remained common among Big Iron into the 1980s). I think this page rightly concentrates on filesystems which are still in active use (or at least it did; I see a few obsolete ones have been added). 18.26.0.5 22:39, 20 July 2005 (UTC)

IBM Mainframe batch-type operating systems such as MVS or OS/VS1 had a type of file system in which basically you allocated space for a file, then gave it a name, then indicated if it was to be kept on the system, deleted at the end of a job step (sort of like allocating a temporary file for use while a program was running), deleted at the end of the job (because the file was being used to hold data from one job to the next, similar to a pipe on Unix), or kept. You usually just stated how much space to use, either by cylinder or track (and the amount to add if you had to add an extent) but the O/S at least, knew where to put the file. I don't know if they had a name for the system. Paul Robinson 13:59, 12 February 2006 (UTC)

RT11 was Digital Equipment Corporation's single-user operating system for their minicomputers. Similar to MSDOS, but with more limitations. 6+3 file name structure (as opposed to 8+3 for MSDOS) the only valid characters in a file name were a-z, 0-9 and maybe one or two more characters. All file names were upper case, and were stored in a format called 'Radix-50' that allowed them to get three characters into two 8-bit bytes (basically by storing file-name characters as roughly 5 1/3-bits each. The machine's basic programming structure was octal. Paul Robinson

As I understand it, Multics went through at least two file system generations, with a New Storage System project in the 1970's which picked up a whole commercial operating system, dug a new basement, and set the system down on top of it without breaking a dish; would be very interesting if one of the Multicians familiar with the project filled in two rows in the table on this page. --Sommerfeld 19:28, 1 May 2006 (UTC)

Directory indexes

What filesystems can lookup filenames from a binary tree or similiar to avoid scanning through all files sequentially to find the one they're looking for? Especially important in large directories, eg. mail files in maildir.. I know ext3, reiser and xfs at least has them.

HFS+'s directories are implemented with a big B-tree, the Catalog File, the key being a combination of the file name and the Catalog Node ID (CNID, think "inode number" from a UN*X standpoint) of the parent directory. See the "Design" section of the page on HFS. -- Guy Harris 01:03, 22 September 2005 (UTC)

NWFS

The NWFS/POSIX cell displays '?' and I'd like to change it. But I'm not sure if it's a 'Yes' (with a Note?) or a 'No'. NWFS does have a ACL capabilities, called Trustees and similar to NSS, but no POSIX interface. JoetjeF 20:54, 26 August 2005 (UTC)

Sparse files

NTFS has this feature called sparse files. Basically, rather then storing a incomplete/file with lots of zeros as a full size file, you only store the data you have. Of course, this does result in a lot of fragmentation, especially if you use it with P2P where you get lots of different portions in different areas, which is probably it's most common use nowadays (although I think it was added long before P2P). I don't know if anything else has it but it would be worthy of inclusion. Perhaps data compression can do the same thing as well but sparse files is somewhat different and simpler! 60.234.141.76 16:47, 17 September 2005 (UTC)

Most UN*X file systems support sparse files; support for them dates back at least to the Sixth Edition file system. (HFS+ is an exception, although it didn't start as a UN*X file system.) -- Guy Harris 00:54, 22 September 2005 (UTC)
I do not understand what you mean to indicate about HFS+. I believe that HFS+ does support sparse files on the volume level (just the OS may not be providing API calls for it, but that's not the point here, right?). Also, UDF supports them (I am very sure of that). Tempel 23:27, 16 March 2006 (UTC)
OS X definitely provides API calls for creating sparse files - lseek() and write(); it's a UN*X, after all. However, all the extents of an HFS+ file are assumed to be adjacent (the data in extent N+1 comes immediately after the end of the data in extent N), so there's no provision for holes in the file, and the HFS+ implementation has to put zeroes in a hole. Guy Harris 00:39, 17 March 2006 (UTC)
Most unix file systems will allocate blocks if you write to them -- even if you write zeros. ZFS with compression enabled will (as a special case) compress an all-zeros block out of existence, turning it (back?) into a file hole. Finding hole edges is another issue with hole API's. Shortly before ZFS integrated, Solaris also grew two new lseek() opcodes: SEEK_HOLE and SEEK_DATA to permit holes to be found efficiently. --Sommerfeld 20:01, 1 May 2006 (UTC)


"Rich file-type meta-data"

How is that defined?

At least in FreeBSD, UFS1 and UFS2 support extended attributes as short named data items; I think at least some Linux file systems do so as well. How does that differ from what HPFS, for example, offers? Perhaps no desktop environments on FreeBSD or Linux use extended attributes for that purpose, but that's not a file system issue. Should "Rich file-type meta-data" be called just "extended attributes", perhaps with a footnote explaining what that means? Guy Harris 08:10, 29 December 2005 (UTC)

I think so, yes --80.98.38.69 12:50, 6 January 2006 (UTC)


UNIX "FS" file system

To what does the item for "FS" refer? The file system that was used in Version 6 Unix, and possibly some earlier versions (I don't know how far that file system goes back)? The file system that was used in Version 7 Unix, which came out in 1979, and which was different from the V6 file system (it added triple indirect blocks, for example, to allow larger files), and which was the basis of the file system used in 4BSD up to 4.1BSD (with a 1024-byte block size and some other small tweaks; 4.2BSD introduced FFS) and System V (which I think also went to a 1024-byte block size)? Guy Harris 08:22, 29 December 2005 (UTC)

The 'FS' filesystem in unix was the first unix filesystem. The 'FS' stands for (surprise!) File System. --ssd 14:44, 6 January 2006 (UTC)
Note that "the first unix filesystem" wasn't the file system in V7 or SIII or SV - there was a significant change between the earlier file systems and the one in V7, the latter being the one on which the SV file system is based. Guy Harris 21:03, 6 January 2006 (UTC)

Anti-SCO sentiment yielding incomplete article

I don't see mention of HTFS. Any reason?

Is that the HTFS from Crosstor, formerly Programmed Logic? If so, I'm not sure how the absence of it would be due to "anti-SCO sentiment", given that it wasn't developed by SCO; the people who formed Programmed Logic left AT&T long before SCO bought the rights to UNIX.
Perhaps nobody who knew enough about HTFS to contribute to the article was aware of it? I've seen no evidence that the absence of HTFS information is due to "anti-SCO sentiment"; do you have any evidence that it is?
If you know enough about HTFS to contribute, you can make the article more complete.... (It still won't be "complete", as there are probably plenty of other file systems that aren't listed.) Guy Harris 18:27, 3 January 2006 (UTC)
Thanks for the clarification on the history of it. I'll add it what I can to at least get it on the map.


Tail packing vs Block suballocation

How is tail packing different from block suballocation? I presume that block suballocation splits a block into even-sized sub-blocks, whereas ReiserFS's tail-packing packs fragments contiguously? --Martin Rudat(T|@|C) 09:36, 18 February 2006 (UTC)

Yes, that's how I understood it. However, technically tail packing can be seen as a special case of block suballocation where the suballocation block sizes are always 1 byte long. Does anyone else think that tail packed filesystems should also have a {{yes}} on block suballocation? -- intgr 14:29, 26 September 2006 (UTC)
I'll create a new footnote for that; anyone who objects, feel free to revert it after responding here. -- intgr 14:33, 26 September 2006 (UTC)


Metadata chart

Just wanted to point out that 'ECC' for the column checksum/ECC goes only to a disambiguation page. —The preceding unsigned comment was added by Deeahbz (talk • contribs) 11:43, 5 March 2006 (UTC)

Just wanted to point out that, as the "Wiki" in "Wikipedia" suggests, you can fix problems such as that yourself, as I just did for the ECC problem (see that for an example of how to go past a disambiguation page). :-) Guy Harris 20:09, 5 March 2006 (UTC)


FATX

For completeness, have started adding the FATX filesystem, as used in the Xbox and Xbox 360. Info on this filesystem appears to be sketchy, but sites such as http://www.free60.org/wiki/Main_Page are proving useful. --OscarTheCattalk 22:38, 7 March 2006 (UTC)


GPFS is missing

IBM GPFS filesystem is missing in this chart. Would anybody like to add it? Thanks. 69.225.127.198 01:25, 15 March 2006 (UTC)

Would you like to add it? :-) That is, after all, what the "Wiki" in "Wikipedia" suggests.... Guy Harris 01:40, 15 March 2006 (UTC)


HFS+ specifics

I took the liberty to make a few corrections to the HFS+ entries in recent days.

I have been writing file systems for the Mac and also wrote the HFS+ generation code for Toast (a popular CD recording software on the Mac), so I have quite a good general understanding, but may still be wrong in some details because I am easily getting confused :^P

A few things I "corrected":

  • Mac names may actually contain NUL characters. Since the Mac uses "Pascal" strings, i.e. those with a length byte/word in front, any char can be stored in such a string. And at least on old Mac OS systems (up to 9.2.2) this actually occured in some cases (I've seen it). However, it _seems_ that OS X is now blocking such names, i.e. does not let you create them any more, but I am not 100% sure on this. But the volume format still allows them.
  • Depending on the API you use on the Mac, there is no limit to the length of paths. That's because the Mac specific "Carbon" API does not use strings to specify an entire path, but instead a combination of a directory node ID and a file name. The node ID is a 32 unique bit value, identifying a file or folder on the volume, and then there's the file name, which is up to 255 unicode chars long. That way, you can create endlessly deep paths.

Tempel 23:22, 16 March 2006 (UTC)

A couple of comments:
  • The API that's ultimately used for *all* file access in OS X is the UN*X API (Carbon runs atop that), so:
  1. file names are components of path names, and path names are NUL-terminated (UTF-8) strings, so NUL characters are not allowed in file names;
  2. all file references are ultimately pathname references, but are relative to the current directory (or to a /.volfs directory hack, perhaps, on file systems that support volfs), so (as is the case with, I suspect, most other UN*Xes) you can, in theory, create arbitrarily long pathnames with the appropriate combination of chdir() and mkdir().
  • The file change logging mechanisms in Tiger is done entirely above the VFS layer, so it's not done by the HFS+ code (that code doesn't even know it's being done), and it's present for all file systems.
Perhaps the "file change logging" column on this page should be used only when there's an on-disk log of that sort, so that it's (in part or in whole) a characteristic of the file system rather than of the OS's file access API. Guy Harris 00:29, 17 March 2006 (UTC)

It seems like the table entry for "case-sensitivity" should really be "partial"; according to the Darwin source code, the only difference between a case-sensitive and a case-preserving HFS system is that a flag is set (google for HFS_CASE_SENSITIVE to find the exact definition).


order

Though I would cringe to do the work, these filesystems should probably be listed alphabetically rather than chronologically. 65.94.60.61 07:16, 27 March 2006 (UTC)

Nah, I prefer chronological. It makes more sense to see the progression of ideas. CTRL-F works well to find things alphabetically. Morcheeba 20:21, 26 April 2006 (UTC)

Transparent encryption is an allocation and layout policy issue?

Compression, maybe, but not encryption. An indication of whether the file system supports encryption might be useful, but it doesn't belong in that particular table. Guy Harris 03:07, 28 April 2006 (UTC)

I've made a bold edit and removed that new column. Suggest we discuss here whether it's worth featuring, and if we decide it's worth having, we only then add it when we can have less "dunno" answers in the column. --Oscarthecat 06:21, 28 April 2006 (UTC)

Missing

At least two common and/or important filesystems are missing from the list: Irix EFS and the Minix filesystem. EFS, contrary to its own article, was the default filesystem in and beyond Irix 5.3. I ran an EFS filesystem for a long time on my Irix 6.2 machine, and that is the way that I received the machine. XFS was available but not commonly used, to my knowledge, for "smaller" filesystems.

As to the Minix filesystem, its importance comes not only from the Minix operating system but also from its use in early versions of Linux, before such novelties as ext2fs were invented.

Someone with more time and knowledge than I have might want to add these. :) Ari 17:38, 1 May 2006 (UTC)


Block suballocation?

I filled in a few blank boxes for ZFS. I think I guessed correctly what was meant by "tail packing". If someone explains what they meant by "block suballocation" I'll figure out whether ZFS uses it. --Sommerfeld 19:54, 1 May 2006 (UTC)

Apple I, Apple II, IIe, II+, III, IIgs, etc...

Is there any documentation on the more common files systems used for the pre-Macintosh Apple file systems? E.g., filesystems for Apple DOS or ProDOS? —204.42.21.95 20:58, 1 May 2006 (UTC)

Inside Apple DOS and Inside Apple ProDOS books. I think there is also an "inside apple pascal" but I'm not sure about it.
Please sign your comments.
—Claunia 23:23, 1 May 2006 (UTC)
I assume you have read these two books and so actually know they contain information on the file systems. Or were you just being snarky? If not, care to elaborate on where online I can find this documentation? —204.42.25.149 03:07, 2 May 2006 (UTC)
I've read one and have both books. Search google, there is PDF and Amazon versions I think.
—Claunia 12:09, 2 May 2006 (UTC)

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)

I believe someone should add a section for Windows CE and its supported filesystems. Tfgbd 21:32, 2 June 2006 (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 will release a new file-system. 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:

  • Don't get confused. Mac OS X uses extension to maintain compatibility with other OSes, but you can change the metadata of the file so it has other application linked (for example files without extension are by default UNIX applications, but you can open old documents and applications without extensions -like Filemaker, Word, QuickTime- and they aren't treated as UNIX apps). —Claunia 22:50, 1 March 2006 (UTC)
  • 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)

Seems that people got confused here. For the question, yes, OS X uses both HFS and HFS+, just it requires booting from HFS+ or UFS. Claunia 14:11, 7 October 2005 (UTC)


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)
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


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:

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


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)

There is no standard nor administrating body. These numbers are used in the BIOS partition table, which is a PC-specific structure that originated with DOS, I believe. It doesn't have anything to do with IDE, SCSI, etc., because it's just an assignment for numbers stored in the partition table on the disk, while ATA and SCSI just provide byte soup. There have been overlaps in the numbers assigned when one group isn't careful not to use the same number as some other group.


HFS+ is Case Sensitive

HFS+J is now case-sensitive (selectable). Edited to reflect that

66.115.245.120 02:51, 25 June 2006 (UTC)JP

You're right, but unfortunately people here have a misunderstanding about what HFSX is. For whatever reason, people think it is a new format rather than just HFS+ rev 2. It'll probably get reverted. -- Steven Fisher 14:27, 25 June 2006 (UTC)


Different meanings of the term "file system"

There are at least two meanings for the phrase "file system":

  1. a set of data structures and algorithms for managing data in a data store, i.e. "a method for storing and organizing computer files and the data they contain to make it easy to find and access them" description;
  1. code that provides the usual set of file system primitives for use by applications running atop it (e.g., something that plugs into an operating system's or desktop environment's virtual file system layer) - that includes the previous description, as well as the "provide access to data on a file server by acting as clients for a network protocol (e.g., NFS, SMB, or 9P clients)" and "virtual and exist only as an access method for virtual data (e.g. procfs)" descriptions.

Is this page intended to cover both of those meanings, or just one of them? The first sentence of the first paragraph discusses the first meaning, while the next sentence discusses the second meaning.

FAT and Long File Names

The article was recently changed to say that FAT32 removed the length restriction on file names... AFAIK, that's rubbish, as long file names work equally well with FAT12 and FAT16. --StuartBrady (Talk) 14:17, 24 July 2006 (UTC)

Perhaps you are right, though I've never seen FAT16 file system be able to have a file name longer than the classic 8.3 format, and certainly the same case for FAT12. If you can provide proof to the contrary, I'd love to see it. --SolarisBigot 14:33, 24 July 2006 (UTC)

Haven't you ever seen long file names with FAT12 on a floppy disk? Also, I was using long file names with Windows 95, upgraded from DOS 6. There was no FAT16 -> FAT32 converter back then. --StuartBrady (Talk) 14:38, 24 July 2006 (UTC)
LFNs (or Long File Names) works with FAT12, FAT16, FAT32 and FAT-X.
—Claunia 14:50, 24 July 2006 (UTC)
All great claims, but we need to see a reference somewhere, hopefully from Microsoft. The data structures in FAT12 and FAT16 do not allow for a long filename. I'm going based upon that. Update: See http://www.microsoft.com/technet/archive/winntas/tips/techrep/filesyst.mspx?mfr=true which has some discussion; it is VFAT (Win95 and later) that added long name support as per StuartBrady's claim. Pure FAT cannot do LFN, as is correct in the article. That's VFAT, which is NOT FAT12, FAT16 or FAT32. --SolarisBigot 15:03, 24 July 2006 (UTC)
Almost right. VFAT was the module in Windows that provided "LFN support". Anyway, you are probably right, but I don't think it's as clear as it could be... "Older versions of the FAT file system (FAT12 and FAT16) had file name length limits [...] FAT32 lifted many of those limits". A reader, might assume that long filename support was one of them, especially since it's already a common misconception. --StuartBrady (Talk) 16:07, 24 July 2006 (UTC)
Noted, and I will take a look at cleaning up those references which are confusing. --SolarisBigot 16:15, 24 July 2006 (UTC)
Thanks! BTW, reading the MS page you linked to, I see that they refer to it as VFAT, so that name is fine. It's probably still more accurate to refer to is as LFN support, but I don't think that really matters. (They most likely called it "VFAT" because that name is better known.) --StuartBrady (Talk) 16:20, 24 July 2006 (UTC)
Fixed. The official name is VFAT, it was implemented as a VxD (virtual device driver) in Windows 95, was originated in Windows NT 3.5, and portions were even backported for WfW 3.11 (but only for 32-bit access). See the FAT page for more discussion, including the gory details on VFAT (there's a section called VFAT and LFN). Hope this addresses your concern. Thank you. --SolarisBigot 16:25, 24 July 2006 (UTC)


Filesystem or file system?

People usually use both "filesystem" in one word, or "file system" in two words and even within one and the same text, you very often see those two variants mixed. If there exists something interesting to say or some recommendation about which to use, then add it.

The same could be said about filesize, filetype, etc. --by anonymous user 83.78.187.157

i prefer seperation into two words which makes it imo easier to read and seems to better fit into the common usage of the english language. --Pythagoras1 15:59, 12 February 2006 (UTC)
Linguistically spoken, the two words may be more correct. However, in common informatics language, the single word is much more in common use. Unlike Pythagoras, I even find the single word easier to read as it comes forward as one specific term. I would thus prefer the single word as title for the article! LHOON 11:11, 14 December 2006 (UTC)


Tools (resize,defrag,undelete)

A table of the available tools is missing. Tools that come to my mind are: shrink / enlarge (offline or online), defragment (online/offline), undelete, shred.--Hhielscher 23:09, 29 June 2006 (UTC)

I'd like to second a request for adding tools, especially whether or not a filesystem can be grown or shrunk. I was all jazzed to pick XFS until I learned that XFS filesystems can only be grown, not shrunk, so this information would be helpful. --Trixter 16:46, 12 October 2006 (UTC)
Sounds like a request for the comparison of file systems article. No comparison tables on the file systems article itself, please. -- intgr 17:15, 12 October 2006 (UTC)


Question about Limits

I'd like to see columns "number of files per directory" and "number of files per filesystem" added to the limits section --WhiteDragon 20:19, 9 August 2006 (UTC)

FAT16 was introduced with DOS 3.0

FAT16 was introduced together with the IBM PC AT and with DOS 3.0. So the table in "General information" should be changed.

Special-purpose database

The second paragraph of the introduction says that it’s debatable whether a file system is a special-purpose database. But that seems to be the article’s only mention of that debate. If it’s so important to warrant a mention in the introduction, then the article address the topic in more depth. And could someone please provide some citations (say, one anti, one pro) regarding the debate? --Rob Kennedy 04:23, 15 September 2006 (UTC)

FS comparisons; FAT and Unicode support

FAT's Unicode support is 16-bit, and for some periods in history the use of UTF-16 surrogates was unsupported or prohibited. I think that under XP there's a registry setting that enables UTF-16 filenames, and I'm not sure that the default state is set (I expect this would affect NTFS as well). Whatever the specifics, I think that the assertion that Any Unicode character is supported is under-qualified. --ToobMug 11:14, 13 October 2006 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:File_system/Archive_1&oldid=1062236406"