Talk:Fork (file system)

This article has been renamed after the result of a move request. No support, opposition, or discussion other than the nomination was given. Dragons flight 00:04, August 26, 2005 (UTC)

cleanup[edit]

The first section doesn't flow. The first paragraphs fit together and talk about apple's implementations, but it's obvious that the next paragraphs are simply tacked on by random people saying "hey foo also had this."

Rewrite.128.114.60.225 (talk) 00:38, 22 October 2008 (UTC)[reply]

Merge Resource fork with this article?[edit]

At Talk:Resource fork I dropped the idea to merge these two articles. —Preceding unsigned comment added by 194.145.122.175 (talk • contribs) 12:36, May 30, 2007

Added security info[edit]

I just added lots of info about the security issues of ADS streams on NTFS filesystems.

--gorgan_almighty 11:52, 28 November 2005 (UTC)[reply]

Important links being removed[edit]

Why on earth did you remove ALL of the Diamond Computer Systems? Okay only one of them was needed but the external link at the bottom should remain. That link provides important information on the subject and is not spam as you have termed it. I have restored the external link to the site at the bottom.

--gorgan_almighty 14:24, 28 November 2005 (UTC)[reply]

Only one link is needed. You added three diamond links on this page, and two to the NTFS page. That does seem like an attempt to spam Wikipedia. Also please note you should only wiki-link the first instance of a word. AlistairMcMillan 15:57, 28 November 2005 (UTC)[reply]

Microsoft's implementations[edit]

Microsoft implemented forks in HPFS, HPFS386, NTFS and CIFS, but your comments only apply to Windows applications (not even to NTFS itself, as I said in NTFS discussion). Also you are wrong saying that M$ implemented forks in NTFS for Macintosh clients. It was also for OS/2 clients (through SMB/CIFS networking) and workstations/servers (installing NT over OS/2's HPFS/FAT and converting to NTFS).

Please correct your words.

—Claunia 00:46, 29 November 2005 (UTC)[reply]

It was actually me that added the Mac reason for NTFS forks. :) [1] All the sources I've seen say forks were added to NTFS so Microsoft servers would work with Macs as well. Do you have a source on why forks were added to HPFS?

Does OS/2 make it easy to see their version of forks ("extended attributes" right?) within the Workspace? Does a files size include the size of extended attributes, or does it just pretend they aren't there like NT? AlistairMcMillan 21:20, 29 November 2005 (UTC)[reply]

It shows, in Workplace Shell (Workspace is the interface of NeXTStep, the OS/2 one is Workplace Shell) and in CMD directory listings. In the old file explorer of OS/2 1.x I don't know, never checked.

Forks where added to OS/2 to store resources as well, but less intensively than in MacOS.

—Claunia 21:26, 29 November 2005 (UTC)[reply]

Technical information relating to security issues on Windows[edit]

Any file can be embedded in another file's ADS stream very easily. The syntax is as follows:

type C:\path\to\virus.exe >C:\path\to\textfile.exe:virus.exe

The file can then be run from the Command Line, a Windows Shortcut, or the Windows Registry as follows:

C:\path\to\textfile.exe:virus.exe

Other important points to note are:

The file size of the ADS stream will not be reported in Windows Explorer or any other program that relies on the Windows API. A 10 byte text file could have a 5 MB ADS stream attached to it, and it would still be reported as 10 bytes.
There is no way of determining if a file contains an ADS stream. The stream can only be accessed if you know it's name.
There is also no limit to the file size of the ADS. A 10 byte text file can have an ADS of 2 gig. This can potentially be used by a Trojan to fill up disk space on the hard drive, and you'd never be able to find where it all went.
Currently, very few virus scanners can scan the contents of ADS streams, however there are now a number of third-party tools that can remove ADS streams.
ADS streams can only exist on NTFS file systems. They cannot exist on FAT32 file systems, and they cannot be transferred across the web or through E-mail. They can however to transferred through Shared Folders if both the source and the recipient use NTFS file systems.

Hope people find it useful.

--gorgan_almighty 15:33, 29 November 2005 (UTC)[reply]

"There is no way of determining if a file contains an ADS stream. The stream can only be accessed if you know it's name." That bits not true, there are ways of iterating through streams. This program does it: http://www.nirsoft.net/utils/alternate_data_streams.html "ADS streams can only exist on NTFS file systems." Thats also not true. NTFS was created to deal with HFS files. There are also other filesystems that support ADS. - Anon

A quick suggestion[edit]

I'd just like to say that I'm happy with this page now. I think we've reached a good compromise. I think a small comment should be made about the virus risk on all of the articles for the filesystems that it affects. Perhaps the Windows Explorer article as well. Perhaps something like:

"Note that some virus' have been known to take advantage of Fork / ADS features."

"Windows Explorer limitations: Windows Explorer is currently unable to detect the presence of ADS streams inside a file. Nor does it report the size of a file's ADS stream. This makes it harder to find and remove unwanted or potentially harmful ADS streams on filesystems that support them."

What do people think? And if not why not?

--gorgan_almighty 12:27, 30 November 2005 (UTC)[reply]

It is already commented, you see, "Windows is affected by almost all of these problems"

—Claunia 12:58, 30 November 2005 (UTC)[reply]

Where are you quoting from?

--gorgan_almighty 13:48, 30 November 2005 (UTC)[reply]

Fork (filesystem) article: "Currently all versions of Windows suffer from all of these problems."

—Claunia 13:59, 30 November 2005 (UTC)[reply]

Wikipedia must be a useful resource, not just a technically correct one. Users will not be aware of the security issues raised on this page because they will never visit this page unless the security issues are mentioned on other relavent articles. In this case it is the filesystems and Windows Explorer articles. If there is no indication on the Windows Explorer article that Windows Explorer has issues with ADS, then users will never visit the ADS article to find out what those issues are.

—gorgan_almighty 14:48, 30 November 2005 (UTC)[reply]

This IS NOT a security page. Microsoft has security pages, there is google, so on.

THIS IS AN ENCYCLOPEDIA. Here peoples comes to know WHAT a thing is, not their security risks.

Here peoples comes to know what is a car, not to learn how to drive it securely, to know what an ABS is, not to know if it is safer than standard brakes.

This is out of discussion.

—Claunia 15:51, 30 November 2005 (UTC)[reply]

An encyclopedia is more than just a glorified dictionary. It does more than just define terms. Paper-based encyclopedia's are very limited on space, but wikipedia is not (not it terms of text anyway). Wikipedia should therefore try to be as helpful and as comprehensive as possible. Security concerns with a certain application or file system are an important piece of information to anyone who is interested in reading about that application or file system, and should be documented. The fact that the information exists outside of wikipedia is irrelevant. Wikipedia should be comprehensive enough to document the concerns itself.

—gorgan_almighty 16:51, 30 November 2005 (UTC)[reply]

Sorry but this has been discussed a number of times before. Wikipedia is not here to inform people about security problems. If you want to know about security problems you don't start paging through an encyclopedia. AlistairMcMillan 17:00, 30 November 2005 (UTC)[reply]

I think that whenever the security issue is notable, it becomes worthy of mention, with as usual references to relevant sources. At the very least, a mention can be put into a "disadvantages" section (if such a section exists and a "security considerations" section is not worth creating). This is similar to how RFCs or manual pages will include a short "security considerations" section where necessary, and an encyclopedia is supposed to collect relevant knowledge, albeit in an abridged form accompanied by references. This is also similar to "health concerns" sections where such research exists. 66.11.179.30 (talk) 16:25, 21 July 2010 (UTC)[reply]

You do realise you are attempting to participate in a discussion that fizzled out five years ago, right? AlistairMcMillan (talk) 09:48, 22 July 2010 (UTC)[reply]

Of course. The discussion is still here for everyone to see and follow so I don't see how this is a problem (especially if you could even read it today :). I think that I'm fine with the current notes in "Possible security and data loss risks" though, and am simply noting to future editors that it is worthy information that should not be removed. Thanks, 66.11.179.30 (talk) 21:20, 23 August 2010 (UTC)[reply]

EAs in FAT?[edit]

"Windows 9x is also affected, as it is not aware about the EAs in FAT!"

FAT isn't an ADS-enabled filesystem, so what are EAs?

--gorgan_almighty 12:27, 30 November 2005 (UTC)[reply]

Read the FAT article.

EAs are "name=value" alternate data streams introduced by OS/2, and used also by Windows (NT series) in FAT12 and FAT16 filesystems.

So, it is an ADS-aware filesystem.

—Claunia 12:59, 30 November 2005 (UTC)[reply]

Compression Formats[edit]

Can ADS streams exist in ZIP or other compression files? —gorgan_almighty 14:51, 30 November 2005 (UTC)[reply]

PkZIP's ZIPs yes, WinZIP's ZIPs not, Microsoft ZIPs not, Microsoft CABs not, RARs yes, it depends.

—Claunia 15:53, 30 November 2005 (UTC)[reply]

Error regarding Macintosh usage[edit]

"HFS was designed to use resource forks to store metadata about a file that would be used by the graphical user interface (GUI) of the Apple Macintosh, such as a file icon or an image preview. However the feature was not limited to GUI data, so additional uses were found…"

This is horse hockey. Resources were much more general from the very start (in MFS, which predated HFS) – applications generally had no data fork, as code and data were stored in resources ('CODE' and 'DATA' resources, logically enough). —The preceding unsigned comment was added by Ahruman (talk • contribs) 21:36, 1 May 2006 (UTC)

Do you have sources to back up your comments about MFS? About HFS, whether you are right about MFS or not, how does that affect HFS? Were applications on HFS stored in the same way? Do you have sources to back that up? AlistairMcMillan 22:00, 1 May 2006 (UTC)[reply]

The format of applications wasn’t changed for HFS; “Classic 68k” Mac apps are resource-based regardless of file system, and CFM-68k and PowerPC based apps for pre-OS X Mac OS are partly resource based (the code is in the data fork, but necessary metadata is in the resource fork). Also implied in my comment is the fact that MFS had forks before HFS. I’ll trawl developer.apple.com for old docs some time when I’m properly awake. -Ahruman 22:14, 1 May 2006 (UTC)[reply]

Firstly if you take a second to read the article again, it doesn't suggest anywhere that forks originated with HFS. Just that HFS is the most likely place to have heard of them.

Here is a page that confirms what you are saying about Classic apps: http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-11.html Can't find one that describes pre-OSX HFS apps as clearly though. AlistairMcMillan 22:24, 1 May 2006 (UTC)[reply]

Well, there are comments in a page about Mac OS history by the programmers, that calls about the Resource Manager, and how the limited executable space of the 68000 forced they to cut apps in resources.

All 68k apps in MFS, HFS and HFS+ are cut in CODE and DATA resources, and you can find more on it seeing the MPW's includes and the Resource Manager chapters of Inside Macintosh books.

—Claunia 23:21, 1 May 2006 (UTC)[reply]

Do you have a link to this page, the one about Mac OS history by the programmers? AlistairMcMillan 01:08, 2 May 2006 (UTC)[reply]

I'm searching it in the logs. As soon as I find it I'll post it here. —Claunia 09:01, 2 May 2006 (UTC)[reply]

Found it!

Resources

—Claunia 09:32, 2 May 2006 (UTC)[reply]

Cool. Thanks. AlistairMcMillan 18:04, 3 May 2006 (UTC)[reply]

"In Computing?"[edit]

Computing seems like a rather large umbrella, including software engineering / computer programming where fork has a very different meaning. Perhaps the beginning of the article should follow the name of the article's lead, and refer specifically to filesystems here. —Preceding unsigned comment added by 70.20.85.161 (talk • contribs) 20:45, August 20, 2006

“Video about forks”[edit]

I removed this:

[http://csc.fsksm.utm.my/shukor/misc.html This] video illustrates how a file is being forked in ADS and one of the methods to remove ADS files.

Seems the address is now unreachable, and further more, a Google search for that URL, shows it is suspected to contain malwares (you get a warning page when you attempt to access the page from Google's search page). --Hibou57 (talk) 13:53, 8 September 2012 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on Fork (file system). Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive https://web.archive.org/20080225103633/http://developer.apple.com/macosx/backuponmacosx.html to http://developer.apple.com/macosx/backuponmacosx.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:34, 10 January 2016 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on Fork (file system). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:51, 4 October 2017 (UTC)[reply]

The first of them isn't dead yet, so I fixed it. The second one works. Guy Harris (talk) 05:35, 4 October 2017 (UTC)[reply]