Re: SPIN problem?

[tlang@limes.de (Torsten Lang)]

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?
> 
> - 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
after a forced media change (which is not possible on a shell!) the contents
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).
I think it would be better to have a mount utility like for GEMAR.XFS. That
could solve some problems under MiNT...
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???
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...
>
> 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)?
>
> Opionions? Hints? Bugfixes?
> 
As I said: I have the impression that Domains are mixed up...

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.