Oh? Which one? Did you find it was because of UMSDOS ? If so, I'd like to
hear about that.
>see a variant of it that would most likely be far more stable with far
>fewer problems than the current UMSDOS distro is...
Actually, UVFAT would be more fragile than UMSDOS. Let me elaborate. UMSDOS
currently keeps _ALL_ data in one file, called --LINUX-.---. So it only
cares about FAT block allocation, not a little bit about MSDOS directory
entries. It does however update MSDOS dirent's on every file create/delete,
but not bease it needs them itself, but because you could boot MSDOS and
access that files also from there (and not get allocation errors on CHKDSK
in DOS etc). It is very tolerable to mismatches between --LINUX file and
MSDOS directory entry (it corrects some of them on the fly, and other on
umssync after boot).
UVFAT would split centralised directory entry management in two places,
--LINUX file, AND directory entry. Mismatches would me much harder to
tolerate. I cannot see why you think it would be 'more stable' (or why do
you think UMSDOS is 'unstable', for that matter)
>Basically, as I understand it, the following is true:
>
> 1. UMSDOS assumes that the underlying file system is the MSDOS
> FAT file system, with its 8.3 limit on filenames.
Yes, it is currently the case. It is feasible to change that, as UVFAT
patches have shown once upon a time.
> 2. UMSDOS places an extra file in every relevant directory that
> provides the extra information that Linux expects to find.
>
>I have NO problem with the latter fact - indeed, I see it as a
>necessary and important step in the process. However, I have to
>question the wisdom of the former fact, which doesnae make any sense
>to me.
There is no wisdom in it really. It was made when VFAT didn't exist.
But we had MSDOS, and wanted to use it for something more, which had
UN*X FS semantics.
>My preference would be for UMSDOS to assume the underlying file system
>to be the VFAT file system, which has already done away with that 8.3
>limit on filenames, as it would then have a much easier time in adding
>the relevant extra properties than it does at present.
It would be pretty much the same level of complication (if not more, see
above), since you would have to have separate extra properties, only one
less of them (LFN. You would still need owner, group, permissions...)
>One ESSENTIAL requirement for that to be true is that the UMSDOS based
>install is more stable than its M$ based competitors and my experience
>of UMSDOS based systems currently says otherwise...
I doubt that anything could manage to be less stable than M$ stuff.
> > untfs wouldn't be bad either. Meanwhile, I wait eagerly for a
> > umsdos boot to work on my PS2 with 2.1.
>
>I wouldnae hold your breath since, with the current rate of progress,
>2.3 will be here first...
Come on. Last 10% of the job DOES take the 90% of the time. The most bugs
are straigtened out, there are actually only few nuisances left (and Rick's
problem which is more than nusance) -- they are hard to track and harder to
reproduce, though. Most other UMSDOS pseudo-root machines do manage to boot,
and do well after that also.
Rick did report the probem, and I *AM* trying to track it down and fit it
into large group of successful pseudo-root boots.
As for untfs, yes, there definitely will be 2.3. here first. It is little
late for 2.1.x to include stuff for 2.2 which is not even in design phase
yet.
-- Opinions above are GNU-copylefted.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/