Re: SPIN problem?

[Julian Reschke-FJR010 <Julian_Reschke-FJR010@email.mot.com>]

tlang@limes.de%INTERNET wrote:
> 
> Hi Petr,
> >
> > I have burnt my first data CD under WinNT. The CD writting software
> > offered three options of ISO9660 filesystem names: strict ISO 8+3, or
> > DOS 8+3 (more ASCII codes allowed), or WinNT fs (up to 128 chars). As I
> > needed to read the CD under TOS and DOS (didn't need long filenames), I
> > chose the middle option, DOS filenames.
> >
> Well, if you really want to be sure that your CD is readable under all systems
> supporting ISO9660 you should choose strict ISO. WinNT fs is quite strange -
> may be what is meant is "Joliet" but in this case it should be able to use
> up to 255 chars per filename...
> >
> > Now the CD is fine under both DOS and TOS, but under MiNT (CD-Tools
> > driver + SPIN 0.34 driver) it behaves strangely:
> >
> Does the CD-Tools driver support long filenames? is it an XFS?

The CD-Tool driver he mentions probably acts as BOS driver. The SPIN
driver
probably is the MiNT XFS, which of course supports long filenames.

> > - Thing 1.20 (and other system tools) shows all filenames on CD in upper
> >   case (which is probably right, all TOS filenames are in uppercase in
> >   Thing)
> >
> > - bash's TAB feature (filename autocompletion) shows filenames in upper
> >   case (which is probably wrong, when compared with autocompletion on
> >   native TOSfs drives)
> >
> > - ls (GNU fileutils 3.9, KGMD) shows all filenames in lower case (OK)
> >
> > - find /r/ -name "*" -print does list only folders in root in lower case
> >   but cannot go recursively into them (probably because it lists the
> >   folders in lowercase while they're actually in uppercase for MiNT, so
> >   it can't CD (change dir) into them and so can't list the entire dir
> >   tree).
> >
> > my problem is that 'find' (GNU find 4.1, KGMD) is basically unusable on
> > this CD.
> >
> I have the same problem with "CDROM.XFS" from Steffen Engel (which doesn't seem
> to be supported any more - kinda wasted money). Even more: When entering some
> directory levels under Thing (no matter which version) Thing crashes (no matter
> if used under MiNT or MagiC - CDROM.XFS is for both systems). Quite interesting
> that MagX-Desk works fine, the same with MiNT specific shells (except for the
> upper/lower case problem).
> I also found the problem that TOS and MiNT domain seem to be mixed up which
> leads to these strange effects you described above.
> There's another problem with both drivers (SPIN and CDROM.XFS): Diskchanges are
> not handled correctly! After changing a CD the drive seems to be empty. Only

Well, here they are... 

> after a forced media change (which is not possible on a shell!) the contents

Obviously it can be done with a program, like forcemed.app which is in
the
SPIN distribution.

> of the CD appear. With SPIN the behaviour was even worse depending on the
> Version of MiNT and SPIN: When using a shell to access a CD the effect described
> for media changes on CDROM.XFS also happened without changing a CD.
> But there are also conceptional problems in SPIN which kept me from using it:
> Different operating modes are set via forced media changes. How the hell shall
> I - as mentioned before - do a forced media change on a tcsh (as I'm writing
> these lines GEM (N-AES) isn't even loaded).

Use the supplied utility.

> I think it would be better to have a mount utility like for GEMAR.XFS. That
> could solve some problems under MiNT...

A mount utility is in fact planned.

> Another important item is that it needs a special METADOS which doesn't load
> DOS drivers. So what shall you do if you additionally HAVE to load a DOS driver
> for another FS???

Load it. Just make sure that the DOS driver file for CD-ROM access does
not
exist, so MetaDOS won't load it.

> While the problem of CD-ROM filesystems is solved for a long time on the Amiga
> it seems to be a big deal on the Atari... When I see the possibilities of my
> Amiga's CD-ROM driver (Images on Photo CD are converted on-the-fly to Amiga-
> native formats, audio-data can be extracted in six different formats
> (on-the-fly in two modes: non-streaming for Plextor drives - the only ones
> perfect for audio data and streaming for the rest of the world), Rockridge is
> supported, Mac HFS is supported in two different ways, you can mount CD images,
> you can configure a lot of things like cache etc.) - well SPIN seems to be a step
> in the right direction...

Thanks. Most of these things work in SPIN as well.

> > When I tried correctly created ISO+RR CD with long filenames, all
> > programs mentioned above were showing filenames correctly.
> >
> Well, under CDROM.XFS at least the Thing crashes also happen here...
> >
> > So I *think* that it's a hidden feature of SPIN that *some* system utils
> > (ls, find) show 8+3 DOS filenames in lowercase while other (bash, system
> > part of find?) show uppercase. Under MiNT all DOS filenames on CD should
> > probably be in lowercase, to be compatible with TOSfs drives.
> >
> Seems to be more a bug ;-) But at least - it's not SPIN specific...
> Problem is that we can't solve it since we don't have sources and therefore
> cannot track down the problem...
> There are two solutions: Julian Reschke does some work on SPIN to make it
> more system friendly or we have to write a new XFS where sources are available -
> but who should do that (costs some time)?

I am doing quite a lot of work on SPIN!, but first a problem needs to
be understood before it can be fixed.

> > Opionions? Hints? Bugfixes?
> >
> As I said: I have the impression that Domains are mixed up...

Which would mean?

> At least I want to mention a completely different problem concerning long
> filenames >32 chars: Some Shells (sh, tcsh) are compiled with a limit of
> 32chars per filname. So when you create files with longer filenames the
> filename expansion (wildcards or <TAB>) does not work for these and any other
> files physically behind in the directory.
> 
> If someone has the time it would be a good idea to check for such problematic
> programs (e. g. tar works fine, tcsh not...!), mainly the shells and recompile
> them.

Regards, jr