linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: peter swain <swine@pobox.com>
To: C Iglesias <unchero@yahoo.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: supporting EAFS (a SCO sysv fs variant) under linux
Date: Tue, 25 May 2004 00:00:48 -0700	[thread overview]
Message-ID: <20040525070048.GC8724@swine.dyndns.org> (raw)
In-Reply-To: <20040520152320.45264.qmail@web21001.mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 3181 bytes --]

Carlos,
I don't have patches for 2.2.14, but would like to help by porting
my support for SCO's sysv-fs variants AFS/EFS/EAFS and the associated
'divvy' partition table support to linux-2.[246], as I haven't touched
it since 2.0, and haven't rigorously tested it since linux-1.3.
Unfortunately I'm quite busy this week.

[cc'd to linux-fsdevel in case anyone else has tools for this, or is
 interested in legacy filesys support]

As I recall the whole linux sysv filesystem project needs to be ported
forward -- there's much other useful compatibility code languishing
there since KGB got distracted to other things (and me too).

I don't have a SCO system to test against, nor even any known-good
SCO EFS/AFS/EAFS filesystems, so if you'd like to send me a small test
filesystem (perhaps containing the tree produced by the attached mk-sco-test)
I could verify directory behavior when i get around to doing this
porting, but I don't forsee much time to port it this week.

Apart from the pre-PC partition scheme (divvy), there are two variants
of sysv filesys here
-- EFS allows filenames >32 chars, by chaining name fragments in consecutive
   dirent slots, with d_ino==-1
-- AFS replaces sysv freelists with inode & block bitmaps
-- EAFS does both

this was developed without inspecting any SCO code, to obtain access to
ny data despite the undocumented filesystem format.
Performance is not great, as you'd expect with a directory format which
has so much messy handling, but it worked read/write quite reliably.

sco 3.2r4.3 was the version that made the filesystems I was using,
so you do have the right patcbes here.

I don't know if you're familiar enuff with linux filesystem internals
to port these patches, but vfs was vastly rewritten, and it will require
some familiarity with old and new filesystem disciplines.

I hope you're familiar enuff with patching and building linux kernels
to build and test with a tentative patch, if i can come up with one.

Probably worth creating a usermode tool to extract from a disk image,
it's much easier to maintain, and nobody wants to *keep* their data in
this format.  Anyone know of such a tool for other filesys formats which
I could extend for this, rather than reinventing wheel?? (no, not the
dosfs tools, something civilized!)

^..^ swine@pobox.com
(oo)

On Thu, May 20, 2004 at 08:23:20AM -0700, C Iglesias wrote:
> Hi Peter.
> I am interested in Linux and i have seen
> some contributions you have done in filesystems HOWTO
> page
> 
> I need to know how to access an EAFS filesytem type
> from Linux
> The stage is as follows:
>  SCO unix Ver.3.2,R4.3 ( older version because nither
> TCP/ip exists in this system
>   The hard 4Gbytes capacity with EAFS filesystem type
> 
> Also i have a Linux Mandrake 7.0 kernel 2.2.14-15mdk
> with a Hard drive 20Gb and Ext2 filesytem type.
> 
> I need to attach the sco hard drive with the linux
> system in order to get out some data from SCO.
> But  i've not been able to mount the SCO into the
> Linux
> 
> I am sorry but i need you to know if you can help me
> with this.
> 
> I wil appreciate your help
> Thanks and regards
> 
> Carlos Iglesias
> El Salvador, Central America

[-- Attachment #2: mk-sco-test --]
[-- Type: text/plain, Size: 766 bytes --]

#!/bin/bash

## test filenames of different lengths 1..255

## the first part is bash-specific and not portable to
## (eg sco & xenix) other shells w/o research

## the real goal here is to build a tar file which can be
## extracted to a filesystem under test, and the results
## tar'd back up again to compare off-box with 'diff -r',
## checking for mis-named files or corruption

## don't be surprised if 'tar vtz' has names out of order,
## just make sure they're all created

## still haven't had time to look at code, i recall 255 being the
## E(A)FS filename limit. adjust if necessary.

mkdir sco-test
max=255
n=1; while [ $n -le $max ]
do
	name=$(printf "%0${n}d" $n)
	echo $name > sco-test/$name
	let n++
done

tar czf sco-test.tgz sco-test
rm -rf sco-test

           reply	other threads:[~2004-05-25  7:01 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20040520152320.45264.qmail@web21001.mail.yahoo.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040525070048.GC8724@swine.dyndns.org \
    --to=swine@pobox.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=unchero@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).