At http://www.iinet.net.au/~swine/sco_fs you'll find a few patches to the sysv_fs and genhd.c code to allow use on SCO3 (v3r2.4) filesystems (i don't know about OpenServer5, i've never met one). Thanks to Bruno Haible for the basic sysv filesystem code. Should appear as http://sunsite.unc.edu/pub/Linux/system/filesystems/sco_fs.lsm and sco_fs-0.2.tgz in a coupla days. By inspection of SCO-generated filesystems (while trying to extract my data from them), i've deduced that SCO differs from the basic sysv4 filesystem in several areas: - 'divvy' partitons SCO has its own unique brand of extended fdisk partition, with type 0x63 (same as GNU HURD!). The divvy table lives 22K into the base partition and carves that partition up into sub-partitions called divvy-partitions (divisions) after SCO's divvy utility. The start+end addresses of these are relative to the *next* cylinder boundary (or maybe even the next after that, in some cases! (where cylinder contains odd number of sectors)) - AFS filesystem like sysv4, but using bitmaps instead of the chained free-list of blocks (though the inode freelist is unchanged). This is signalled by an s_free count of 0xffff. - Extended File Names The sysv (SCO calls it S51K) and AFS filesystems may be 'extended' to handle names up to 255 chars (rather than 14). These filesystem types are called ES51K and EAFS. Directories entries still have 14-char names (a la sysv), but they're chained by using an inode number -1 for non-terminal chunks, which form a prefix to the next entry. This behaviour is signalled by adding 1 to the super-block magic number (which becomes 0xfd187e21). SCO3's default filesystem type is EAFS, but if you convert filesystems to ES51K, it runs fine (just saying 'Extended File System' instead of 'Extended Fast Filesystem' when it does an fsck). Don't know about SCO5, i've never met one. I've addressed these differences as follows: - EAFS & AFS filesystems can be mounted read-only to leave them unmolested, or mounted with "mount /dev/hda5 -t sysv -o convert_afs", which zaps the bitmap freelist, leaving an ES51K or S51K filesystem, which SCO will handle without you noticing any difference (maybe 5% slower, and you'll have to use fsck to rebuild the freelist next time you run SCO on that drive [or run "/SCO/etc/fscmd.d/ES51K/fsck -f -S /dev/hda5" under ibcs2] - Extended names are handled throughout (when the super-block implies they should be), so the 14-char limit disappears, and any long names which appeared fragmented under the old filesys now join up again. - CONFIG_SCO_DISKLABEL adds "divvy" support to genhd.c, recognising divvy partitions on a sco-formatted drive, and calling them (say) hda5, hda6, ... This is necessary if you wish to boot from a SCO drive. Divvy parallels the function of DOS's Extended Partitions (but evolved for Xenix before DOS developed the concept). - Divvy partitions are also detected by hdinfo_sco, (modified from dosemu's hdinfo util), allowing sco_fs patches to be restricted to fs/sysv module: hdinfo_sco yields a byte-offset-to-filesys, so you can use "mount -t sysv -oloop,offset=XXXX /dev/hdb /mnt". Using SCO filesystems from both SCO and Linux: The bitmapped-freelist EAFS (SCO3 default) filesystems are detected, and forced read-only as the freemaps aren't understood, which makes a *much* faster common-filesys-format than SCO3's DOS fs (which does a woeful 120kB/minute on a 33MHz 486!) Read/Write ES51K works too, and you can then boot Linux or SCO off the one partition (with iBCS2, and a bit of juggling symlinks on /etc & /dev). (Just takes one quick jab with fsdb to convert a filesys from EAFS (ro by linux) to ES51K (rw by both, and mebbe 5% slower), or you can mount with -oconvert_afs) EAFS is a combination of AFS (bitmapped free list on an otherwise S51K fs), and Extended names (255 chars rather than 14). SCO supports both intermediate forms (ES51K & AFS), so you don't notice a thing (except the SCO-fsck banner of "[Extended] [Fast] File System"). History: I've used this code for well over a year w/o hiccups, but haven't had access to SCO systems to preen it against in most of that time. Still has a few ruff edges which i've never bothered cleaning up (haven't adopted the new printk() levels, etc) and contains an overblown mount-option-parser, but my original 1.3 patches (done on 1.3.96) drop seamlessly onto 1.3.62, and without much hand-tweaking onto 1.3.42 or before. Recently I pulled out an old SCO-generated filesystem and checked that it still worked with linux-2.1.30. Coupla trivial .h changes, and it performs as ever. The 2.1.30 patches should apply w/o hiccup to 2.0.0 ... 2.1.33, i think, but i've shipped patches against a 1.3 kernel for help in sussing out how to splice into an earlier kernel. Some warnings about extended names are left enabled in fs/sysv code, please give me some feedback on whether you have any hiccups in this (or any other) area. Consider it Beta -- works for me but I may have missed a few things. Legal Crud: This work contains no code from the Santa Cruz Organisation, and is published under the terms of the FSF's LGPL in the interests of enhanced interworking of licensed SCO systems with other open systems. No Warranty is expressed or implied, use at own risk, your mileage may vary... enjoy ^..^ (oo) -- Peter Swain ^..^ Swine@iinet.net.au swinus ambulatus &,-(oo) http://www.iinet.net.au/~swine layered realities (.___) mobile: +61 419 43 1088 aberrant protocol design /| /| vox: +61 9 384 0188 unique household repairs fax: +61 9 284 3237