cazier@mbunix.mitre.org (Cazier) (09/22/90)
Submitted-by: cazier@mbunix.mitre.org (Cazier) Since UNIX can support different filesystems, why wouldn't it be possible to either define another file structure that would allow UNIX to read/write DOS filesystems, or create some device driver that would interface with /dev/DOS to read/write DOS files and directories? Volume-Number: Volume 21, Number 124
ucbked@athena.berkeley.edu (Earl H. Kinmonth) (09/22/90)
Submitted-by: ucbked@athena.berkeley.edu (Earl H. Kinmonth) In article <536@usenix.ORG> cazier@mbunix.mitre.org (Cazier) writes: >Since UNIX can support different filesystems, why wouldn't it be possible >to either define another file structure that would allow UNIX to read/write >DOS filesystems, or create some device driver that would interface with >/dev/DOS to read/write DOS files and directories? It not only can be done, it has been done. SCO Xenix, for example, allows reading/writing to a DOS partition. There is also a set of tools for doing this on other systems. Volume-Number: Volume 21, Number 125
jfh@rpp386.cactus.org (John F. Haugh II) (09/25/90)
Submitted-by: jfh@rpp386.cactus.org (John F. Haugh II) In article <537@usenix.ORG> ucbked@athena.berkeley.edu (Earl H. Kinmonth) writes: >In article <536@usenix.ORG> cazier@mbunix.mitre.org (Cazier) writes: >>Since UNIX can support different filesystems, why wouldn't it be possible >>to either define another file structure that would allow UNIX to read/write >>DOS filesystems, or create some device driver that would interface with >>/dev/DOS to read/write DOS files and directories? > >It not only can be done, it has been done. SCO Xenix, for example, >allows reading/writing to a DOS partition. There is also a set of >tools for doing this on other systems. I believe what is being referred to is use of the file system switch to support MS/DOS filesystems without the use of special tools or emulators. SCO Xenix has a collection of commands which are intimately familiar with the format of MS/DOS file systems. Thus, to edit a file on a MS/DOS partition, I must first copy the file off of the partition and into a Xenix file. Then I can edit it, and so on. Using the System V file system switch (or vnodes, or xyznodes or whatever ...) would allow any utility to operate on any MS/DOS file on the MS/DOS partition without the need for copying. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson Volume-Number: Volume 21, Number 143
guy@auspex.uucp (Guy Harris) (09/30/90)
Submitted-by: guy@auspex.uucp (Guy Harris) >Using the System V file system switch (or vnodes, or xyznodes >or whatever ...) would allow any utility to operate on any MS/DOS >file on the MS/DOS partition without the need for copying. *Does* allow, at least in the case of vnodes under at least some SunOS releases; Sun Consulting sells (or, at least at one point, sold; dunno if they still do) a DOS file system for SunOS, which Steve Kleiman did as a sort of "proof of concept". Other vendors may have done the same. I'm not sure what all this has to do with UNIX standards, though, as none of the existing UNIX standards specify the on-disk format of UNIX file systems (thank goodness!), they just specify the interface to functions that manipulate files. I don't think the DOS file system can fully support the POSIX semantics of those functions in any case, given the file name limitations, the lack of full UNIX-style permission bits, etc., etc.. Volume-Number: Volume 21, Number 151
seanf@sco.COM (Sean Fagan) (09/30/90)
Submitted-by: seanf@sco.COM (Sean Fagan) In article <555@usenix.ORG> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>SCO Xenix, for example, >>allows reading/writing to a DOS partition. > >I believe what is being referred to is use of the file system switch >to support MS/DOS filesystems without the use of special tools or >emulators. SCO UNIX has this ability. I.e., mount -f DOS /dev/rfd096 /mnt or whatever. What this has to do with standard unix is beyond me, however. Note that NFS will work with a DOS server, which means that, basicly, just about any current unix should be able to mount a DOS filesystem. -- -----------------+ Sean Eric Fagan | "Never knock on Death's door: ring the bell and seanf@sco.COM | run away! Death really hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'. Volume-Number: Volume 21, Number 152
staff@cadlab.sublink.org (Alex Martelli) (10/01/90)
Submitted-by: staff@cadlab.sublink.org (Alex Martelli) jfh@rpp386.cactus.org (John F. Haugh II) writes: ... >I believe what is being referred to is use of the file system switch >to support MS/DOS filesystems without the use of special tools or >emulators. SCO Xenix has a collection of commands which are >intimately familiar with the format of MS/DOS file systems. Thus, Interactive 2.2 has both the collection-of-tools (actually bundled into one, "dossette", which you can run either interactively or not), AND the ability to mount a DOS partition or floppy (it seems that for some reasone you can only mount a DOS partition on a hard disk if that disk ALSO has a Unix partition - don't know if it's a bug or a feature) with the mount -f DOS switch (or mount's auto-fs-sensing feature). It seems a reasonable approach; the special purpose tool is faster for typical usage (grab a few files of a floppy), mounting allows full-range operation. There IS a bug in mounting a DOS12 partition - if you have more than 64 files in a directory, there will be malfunctions (severe ones!); it's also indispensable to up the NDOSINODES undocumented variable (as I believe Conor showed a few months ago) from its default, currently 400. -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night). Volume-Number: Volume 21, Number 170
guy@auspex.uucp (Guy Harris) (10/01/90)
Submitted-by: guy@auspex.uucp (Guy Harris) In Article <562@usenix.org> Submitted-by: guy@auspex.uucp (Guy Harris) >...I'm not sure what all this has to do with UNIX standards. In Article <106914@uunet.UU.NET> Submitted-by: seanf@sco.COM (Sean Fagan) >... What this has to do with standard unix is beyond me, however. I have to admit I agree: I don't know what this has to do with comp.std.unix, either. Suggest we retire this topic. John S. Quarterman, moderator, comp.std.unix and std-unix@uunet.uu.net Volume-Number: Volume 21, Number 153
jason@cnd.hp.com (Jason Zions) (10/01/90)
Submitted-by: jason@cnd.hp.com (Jason Zions) In Article <562@usenix.org> Submitted-by: guy@auspex.uucp (Guy Harris) >...I'm not sure what all this has to do with UNIX standards. In Article <106914@uunet.UU.NET> Submitted-by: seanf@sco.COM (Sean Fagan) >... What this has to do with standard unix is beyond me, however. In Article <106918@uunet.UU.NET> Submitted-by: jsq@uunet.uu.net >I have to admit I agree: I don't know what this has to do with >comp.std.unix, either. Suggest we retire this topic. Actually, it *does* have something to do with standards. Just such a concept, i.e. how to cope with filesystems offering less than full 1003.1 semantics, is a major topic of discussion in 1003.8 (POSIX Transparent File Access). The whole thing started when we decided to divide our scope into two parts: 1) Full TFA, which consists of additional description and the odd interface or two, for networked filesystems that supported full 1003.1 semantics, and 2) Subset TFA, for networked filesystems that provided less than 1003.1 (e.g. NFS, RFS, etc.) Supporting subset TFA meant providing some mechanism for an application to inquire as to precisely which semantics were available and which were not, and that the subset we should permit could be quite small (i.e. core usage of FTAM). Around the time of the Snowbird meeting, we came to the not-so-startling realization that one need not require the subset-semantics filesystem to be at the other end of a network. One could have a local FTAM filestore, for example. Then, we realized that the core subset we'd extracted from FTAM was no richer than the subset of 1003.1 semantics natively supported by the current CD-ROM filesystem standard; since CD-ROMs are becoming increasingly popular devices, perhaps it made sense for 1003.8 Subset TFA to talk about those devices as well. >From the CD-ROM it was a short step to the idea of a local DOS filesystem on a floppy or somesuch, or perhaps accessed over some PC LAN protocol like Netware or LM/X. In other words, the whole thing isn't as far-fetched as it might seem, and it most certainly is standards-relevant. Jason Zions Chairman of, but not speaking for, IEEE P1003.8 POSIX Transparent File Access [ Ok, it's hard to argue with that line of thought regarding relevance. Do let's keep it technical, non-personal, and non-repetitious, however. Maybe you could say more about what 1003.8 is planning to do, in more detail? -mod ] Volume-Number: Volume 21, Number 157