1. Home
  2. Embedded Programming
  3. Micro$oft to license FAT
  4. Page 5

Micro$oft to license FAT

This is all fairly academic, but to extend the 8.3 filename system I see only three basic places to keep the extra information: a) in an auxiliary file b) in directory entries and c) in the file itself.

The 4dos description system is an example of a), and many others can be found. c) is inherently not compatible. b) using previously illegal entries is MsDos's way, and a previous example can be found in the change from CP/M 2.2 to CP/M 3.0 (or to my DOSPLUS 2.5) somewhere around 1983 to 1987. In fact the addition of CP/M user numbers is an even earlier example, and came somewhere around 1978.

The above may or may not be examples of prior art and invalidate any MS patents. Since IANAL and especially I am not a patent court, that judgement must be left to others. My personal opinion is that it does invalidate, inasmuch as I cannot conceive that using a previously known technique for a more restricted purpose is patentable. The restricted purpose itself is antedated by at least the 4dos description system. That leaves the usual Microsoft "innovations" area as its usual nullity.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer
Loading thread data ...

There's a fourth method, which lies somewhere inside the triangle formed by a, b, and c: Multi-stream files, a la MacOS "data fork" and "resource fork". (NTFS has something like this now, I don't know exactly what MS calls it). The LFN, if put in a separate stream, is still part of the file (since it's inseparably associated with that one file), but is pointed to by some extension to the directory entry.

Reply to
Lewin A.R.W. Edwards

Because of the Mac duality, Macs are somewhat doofuses on non-Mac networks. Neat idea, but in practice, it is so incompatible with the world as to further isolate them.

When Macs decide to get fussy, they can be every bit as fun as Windows to set straight, and a major cause of Mac network problems is the resource fork getting lost or misplaced.

Reply to
Bryan Hackney

True, but in a way that can be viewed as c. Back circa 1974, MPE3000 (the OS for the HP3000) provided a file structure with a system and a user reserved special data block, and provisions for creating files with multiple user reserved special data blocks. There was no restriction AFAICR as to what went into these blocks, but access to them could be restricted. I believe this structure was used to implement fairly secure data base systems later.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

The problem is that the MS solution is the only one that MS is unlikely to break in future releases. The alternatives exist and can be used, but if you want long-term portability across MS OSes, you're forced to use the MS solution [regradless of its merits].

Reply to
Geoff McCaughan

Strangely enough, The success of the Philips screw (particularly in the automibile industry in the 1930's) was due to it being such a "bad" design - you could not over torque the screw because the screw driver would slip out of the hole. (read "One Good Turn - the history of the screwdriver").

Apologies if a little off topic.

Denis

Reply to
denis forde

It's an interesting fact that NTFS (Windows NT File System) makes allowance for a arbitrary number of 'meta-files' attached to each file. The 'Data fork' isn't special except in that it contains the data, and in that nobody has implemented any other forks, AFAIK.

Regards. Mel.

Reply to
Mel Wilson

This is somewhat similar to what OS/2 did (which Microsoft helped design initially). However, they were able to do that on a straight DOS compatible FAT file system (optional, since their native filesystem was preferrable). They did implement it in a FAT compatible way, but using a hidden file, rather than tweak FAT in a way that wasn't forward compatible with Microsoft's version.

--
Darin Johnson
    Where am I?  In the village...  What do you want?  Information...
Reply to
Darin Johnson

Actually, it works really well in conjunction with NT's multi-stream feature :) I administer our work LAN, I was *most* surprised to see that when I did a straight drag-n-drop backup of one of the Mac drives [on the NT box itself], all the resource forks were kept and stayed with the correct files. I was expecting to get the data fork only.

Furthermore, it warned me when I tried to copy one of those files to a FAT volume that the resource fork info would all be lost (I forget the exact warning).

Reply to
Lewin A.R.W. Edwards

I (vaguely) remember that. Users could add arbitrary information to the "attributes", as I remember. I think the java compiler kept its output there, too, so sources weren't recompiled unless they changed.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net
Reply to
Alan Balmer

Yeah, they lived (on FAT filesystems anyway) in a big file called " EA DATA. SF" or something similar. Damn thing just got bigger and bigger and kept filling with crud.

I loved OS/2 2.0 when it ran on bog-standard IBM hardware, using HPFS.

I hated, hated, *hated* it on FAT systems and anything with even vaguely unusual hardware - at one point the only way to recover from an attempt to change screen resolution was to reformat the hard disc! (And I think that was only a Trident 8900C!)

pete

--
pete@fenelon.com "There's no room for enigmas in built-up areas."
Reply to
Pete Fenelon

Extended attributes on FAT were a terrifyingly horrific kludge, though. They only worked well on HPFS.

Reply to
Lewin A.R.W. Edwards

networks.

resource

It's not quite true that "nobody has implemented any other forks". There are a couple of applications that make use of multiple data streams in ntfs files, but they are rare, since they won't work on FAT. Also, windows comes with a grand total of zero tools that are data stream aware, so it can lead to no end of confusion and problems. In fact, the only successful multi-stream program I know of is ... wait for it... a virus. It hides copies of itself in alternate streams of exe files, where it is almost impossible to find - the only change visible to the real exe file is a small hook at startup. Fortunately, it did not spread too well, and, being unable to attack most windows machines (running on FAT/FAT32), it was not common.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.