I would define MSDOS compatibility like something which works in union with
all MSDOS supplied utilities without making them report errors. So I can not
accept your declaration that "MSDOS utilities are not MSDOS compatibile".
> If you want an example of this, try installing ANY DOS-based network
> under ANY version of MSDOS from 3.20 through 6.22 inclusive, then run
> such 'Standard' DOS tools as Norton's SpeeDisk (SD) program and watch
> it mangle your entire filesystem in the process...due to the fact that
Eh? I did run both many versions and Lantastic, and Novell's netware (both
3.x, 4.x and Personal), on DOS 3.3, DOS 5.0, and DOS 6.x, and I've NEVER
encoutered such problems. When disk was declared as network, Norton
Speeddisk and such utilities properly refused to run on "network disc".
When network was shutdown, speeddisk and stuff run just fine.
> EVERY last one of those networks added extra fields to the directory
> entry structure, always in undocumented ways, and usually totally
> incompatible with any other type of network as well...and most added
> extra hidden directory entries 'for accounting and security purposes',
> as one network's technical documentation put it...
Novell 3.x did have 'bindery information', but it was all kept in one (or
two? It was long time ago...) system files. But it was not running over FAT
(Novell Server). Lantastic also never had any problem... It saved access
permissions in C:\LANTASTI.LAN or something directories). Can you specify
which newtworks do you mean in 'every last one of those networks' ? And what
they actually did ?
> > Yes, UMSDOS is a kludge also, but (again IMHO) to a much lesser
> > degree and also giving much more than VFAT (LFN is just one thing
> > missing).
>
> I can't fully agree here, although I agree with the general sentiment:
> UMSDOS is far less of a kludge than most of those networks were, but I
> don't personally think it's any less of a kludge than VFAT is...
It does not confuse standard MSDOS utilities, and it provides more
functionality (owners, permissions, symlinks, device files etc.)
> As stated above, the so-called standard MSDOS tools don't work with
> most of the DOS-based netowrking protocols anyway, so one can hardly
> regard them as any form of quality test, as you appear to imply...
That is because DOS-based networking protocols were a kludge; as DOS was
never intended for such stuff in its designs. Single user, single task,
remember? What file locks, record locks ? That would assume that there exist
someone else but one user running one task.
> The last time I tried to make serious use of UMSDOS was with kernel
> 2.0.33 so these comments may no longer apply. However, my experience
> at that time indicated two bugs, both of which I consider major, and
> both of which I reported. As far as I can tell, neither was ever
> addressed:
> 1. UMSDOS was not producing correct short-form names for files with
> more than one dot in them, where the ninth character of the
> filename was a dot. I discovered this when it took an archive I
> created under the name "MemAlpha.Systems.tar.gz" and mangled it
> into "memalpha.sys" - and in the process overwrote an existing
> file in the same directory!
And you report it to current maintainer then ? I do not seem able to
reproduce that problem in last 2.1.x kernels, and don't have 2.0.30 near me
to check it there, but if there really was a problem (as opposed to, for
example, out-of-sync umsdos filesystem), it seems fixed now. So how did you
deduce that it was never addressed ? Did you ever checked ?
> 2. In my opinion, it should respect the standard short forms for
> compressed tarball extensions, but it fails to do so. For your
> reference, I'm used to the following mappings:
>
> *.tar.[Zz] => *.taz
> *.tar.gz => *.tgz
> *.tar.bz2 => *.tbz
Oh ? And VFAT mangles it that way ? I don't think so.
> From experience, it maps as follows:
> *.tar.[Zz] => *.z
> *.tar.gz => *.gz
> *.tar.bz2 => *.bz2
>
> Comments ???
You may find it logical, but it would make mangling much more complicated
and slower and less universal. Also, if new format popped out (like, for
example .bz2 that didn't exist when UMSDOS was created) you would have to
change mangling strategy, thus breaking binary compatibility with previously
created UMSDOS filesystem. Hardly acceptible IMNSHO.
I cannot see how can you classify it as "major bug". The main purpose of
UMSDOS is to give unix-like-fs, using MSDOS FAT storage. The secondary
purpose is to provide access from MS-DOS to the same files -- keeping
extension same if at all possible, mangling filenames in the process.
It was design decision - rather good one if you ask me. You could in the
same logic accuse ext2 that it has a major bug since it is not a logging
filesystem.
> > Do you want to say that you CAN NOT access UMSDOS file in MSDOS, or
> > did you somehow deduced that poster above wanted to say that you
> > cannot access VFAT files in MSDOS ? I see no explanation for any of
> > those reasonings.
>
> {Shrug} The author of the email I replied to emailed me privately to
> apologise for claiming that one couldnae access VFAT filenames in
> MSDOS in the said email, so I feel vindicated in interpreting his
> comments that way...
Then it seems I missed original poster claim. Please disregard my last
comment then.
Matija
-- 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/