Template talk:Infobox file system

Template changes
Disclaimer; I'm a NetApp employee.

The infobox is being used on the NetApp WAFL page (amongst others). Can we discuss changes to more accurately reflect virtualising filesystems like WAFL and ZFS for instance? There's no tag to describe (not an exhaustive list)
 * snapshots (point in time read copies)
 * clones (writeable snapshots)
 * deduplication (elimination of duplicate data in the file system)
 * thin provisioning ("sparse" allocation)

Comments? Thanks. Alex (talk) 11:19, 1 May 2008 (UTC)

Copy-on-write
I add an entry for copy-on-write since this is now a major feature for FS.

Despite the warning on top of this page, I don't think this breaks infobox at File Allocation Table.

Sylvain Leroux (talk) 11:04, 12 March 2011 (UTC)

Website
Need official website section, as in Template:Infobox_OS 93.73.113.242 (talk) 15:11, 16 November 2013 (UTC)

License?
Hello, everyone

Today, (Hello, Tim!) made a rather disturbing contribution: He added a license parameter to the template!

It is impossible to license a file system. It might be possible to hold a patent on it, or license its APIs but not the file system itself.

Okay, Tim@. You might want to start telling us what you were thinking; i.e. what you saw that made you think a license field is appropriate.

Best regards, Codename Lisa (talk) 05:57, 27 September 2017 (UTC)


 * I think he meant the software license for the implementation (e.g. ext4). Often there is no distinction made between the file system and the original implementation of it, so it kind of makes sense, although there are exceptions to this like FAT, ISO 9660, UDF, JFS, etc. Or maybe it's an indication that filesystem articles should also include a Infobox software in a section where they discuss a particular implementation. Sometimes 3rd party implementations also have a separate article, such as NTFS-3G. -- intgr [talk] 09:32, 27 September 2017 (UTC)
 * Hello, intgr
 * We don't need to go so far as adding an . We can deploy an "implementations" section and add those details via compact sub-infoboxes.
 * But let's be realistic: A file system driver that has its own article would probably need nothing more than a Infobox OS component. This infobox does not have a license field because the license of the file system driver is always the same as the OS. (Read the GNU General Public License article to find out why.) The license of the OS rarely changes, and in the event of a change, we mustn't need to update it in the file system articles of that OS too.
 * So to sum it up, OS and introduction OS should be more than sufficient.
 * Best regards, Codename Lisa (talk) 10:20, 27 September 2017 (UTC)
 * Hi Lisa, Linux is a multi license OS, and there are proprietary files systems for it like the Google File System, and there are non-GPLv2 file systems like ZFS which is CDDL, The NLS component of FAT, JOLIET, NT, SMB, etc has a BSD licenses so I think it's useful to list the reference implementation license and the most permissive implementation license when they differ.--Tim (talk) 02:33, 28 September 2017 (UTC)
 * Hello, Tim. Glad to see you drop by.
 * Again, Google File System and ZFS themselves cannot be licensed; only their drivers. Here is an except from the U.S. Copyright law:"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."But your last example makes me think an implementations parameter wouldn't do; we need an "Implementations" section in each article explaining it. Specifically, it is a gray area of the law, for example, as to whether a CDDL driver for ZFS integrated into another work is still licensed as CDDL. Oh, wow! I see the CDDL article has already explained this exact case.
 * Best regards, Codename Lisa (talk) 06:18, 28 September 2017 (UTC)