🚀 go-pugleaf

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

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

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

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

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

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

Submitted-by: aglew@crhc.uiuc.edu (Andy Glew)

>..> Discussions of using the System V filesystem switch to mount DOS directories
>
>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.  

While I understand where the "thank goodness" comes from, I do rather
wish that there were some standards for the on-disk format of UNIX
filesystems.  Or am I the only person that has ever tried to transfer
UNIX filesystems on floppies between different systems?  Or (soon)
transfer UNIX filesystems on floptical disks?

Most of the filesystems standards work seems to be technology specific
- such as, the soon-to-become-official standard for CD-ROM filesystems
and other optical disks.  However, what I've seen of the CD-ROM
standard suggests that I am unlikely ever to be able to mount a CD-ROM
as the boot partition of my workstation...
    Q: what is the UNIX community's particpation in various
technology-oriented filesystems standardization efforts?  Does everyone 
feel confident that present and future UNIX filesystem semantics will be
completely supported by these standards?

--
Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]

Volume-Number: Volume 21, Number 155

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

Submitted-by: andrew@alice.att.com (Andrew Hume)

In article <563@usenix.ORG>, aglew@crhc.uiuc.edu (Andy Glew) writes:
> ... I do rather
> wish that there were some standards for the on-disk format of UNIX
> filesystems.  Or am I the only person that has ever tried to transfer
> UNIX filesystems on floppies between different systems?  Or (soon)
> transfer UNIX filesystems on floptical disks?
> 
> Most of the filesystems standards work seems to be technology specific
> - such as, the soon-to-become-official standard for CD-ROM filesystems
> and other optical disks.  However, what I've seen of the CD-ROM
> standard suggests that I am unlikely ever to be able to mount a CD-ROM
> as the boot partition of my workstation...
>     Q: what is the UNIX community's particpation in various
> technology-oriented filesystems standardization efforts?  Does everyone 
> feel confident that present and future UNIX filesystem semantics will be
> completely supported by these standards?
> 
> --
> Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]


	the x3b11.1 work that i snitch on is aimed precisely at this.
the current work is aimed at WORM technology but the next standard is
for re-writable optical media - which is isomorphic to regular
magnetic disks. however, it is important to note this is an interchange
standard. for various (read performance and economic advantages) reasons,
vendors may always choose a different format for internal use but at least
you should be able to convert this to the interchange format for carrying
the data around. and in x3b11.1's case, we are tryingvery hard to make
the format a plausible one for use as a regular filesystem.
	i agree the CD-ROM standard does not sit comfortably with Unix
but what can you expect when the primary vendors represented on the high
sierra committee were MS-DOS and VMS? x3b11.1 has active participation
from bell labs research (me) and Sun (tom wong) and HP (ed beshore)
to name prominent Unix representatives; in addition, many of the other members
are acutely aware of the importance of the Unix market.

	as for support of present and future unix filesystems, we are
deliberately adding support for arbitrary additional fields per file-like
thing (as extended attributes) so as far as it is possible, we should be able
handle most future extensions. as for present systems, it is up to the
unix community to comment NOW on what fields are necessary. standard
things like BSD/SysV inode fields can be taken for granted but
perhaps you know of others (file effective date? file expiry date?
automatic logging on write access). please mail such suggestions to
andrew@research.att.com. the ball is in the unix community's court.

	andrew

Volume-Number: Volume 21, Number 164