>> I agree that VFAT is a horrible kludge, but I would disagree with
>> its being incompatible with MSDOS FAT - in my opinion, it's far
>> more compatible with it than most of the so-called 'tools'
>> supplied with MSDOS itself.
> 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".
OK then, advise me how to use the MSDOS-supplied APPEND command with
MSDOS v5.00 (with which it WAS supplied) without corrupting the
filesystem! The ONLY way I ever managed to get it to work in the first
place was to use SETVER to dupe it into believing it was running under
MSDOS 2.xx and it invariably resulted in my hard drive being mangled
beyond recognition and needing a reformat!!!
Don't try kidding ANYBODY that the MSDOS utilities were MSDOS
compatible coz they only worked with ONE SPECIFIC version of MSDOS is
MANY cases, but were often supplied unaltered with later versions as
well...
>> 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...
> 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.
I can't speak for Novell Netware as I've never used it, but I was
REGULARLY called in to sort out Lantastic and PC-LAN based networked
PC's under MSDOS 2.11, 3.20, 3.30, 3.31 and 5.00, in each case because
somebody had run RESTORE to restore files to the hard drive after
deleting them, or had run Norton SD (under MSDOS 3.xx) or DEFRAG
(under MSDOS 5.00) to reduce access times to files. Thankfully, in
MSDOS 6.xx this problem had been sorted out and both networks ran
quite happily, but the problem was REAL under earlier versions...
>> 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...
For reference, I discovered SOME of the details of what those two
networks did through a disk editor. PC-LAN added a file whose name
consisted entirely of NUL bytes to every directory, and used the
'Reserved' portions of the directory entry for that file to state
access permissions to the directory as a whole, with the same fields
in every other file used for access permissions to the file. First
time one ran either SD or DEFRAG on the disk, it cleared all those
fields and deleted the additional file entry - thus mangling the whole
disk as a result...
> Novell 3.x did have 'bindery information', but it was all kept in
> one (or two? It was long time ago...) system files.
That's the way it SHOULD be done - one thing UMSDOS definately gets
right...
> But it was not running over FAT (Novell Server).
I didn't think it did somehow...
> 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 ?
See above...
>>> 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.)
I've just had it pointed out to me that the standard MSDOS file system
could be confused by simply running SETVER under MSDOS 5.00 or later,
and using it to run the MSDOS 2.xx version of BACKUP on a >32M Hard
Drive - and that was guaranteed to scramble any hard drive it was
applied to...
Mind you, it doesn't need that sort of chicanery to fool the MSDOS
utilities, unless one is running MSDOS 6.xx or later - they're much
harder to fool...
>> 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.
Agreed - that's one reason why I consider the arguments about UMSDOS
having to retain compatibility with MSDOS utilities a non-starter, as
stated above...
>> 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 ?
I can't speak for the 2.1 kernels, but it was definately present in
2.0.34, the last one I 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.
VFAT doesn't need to since it supports the long forms in the first
place...the whole question is only relevant on filesystems that are
limited in the filename formats they permit.
However, I note that the FTP utility installed on Win3.x systems here
at Aberdeen University uses precicely the above mappings when
downloading files with those extensions, and it announces dear old M$
as the originator thereof...
>> From experience, it maps as follows:
>> *.tar.[Zz] => *.z
>> *.tar.gz => *.gz
>> *.tar.bz2 => *.bz2
> You may find it logical, but it would make mangling much more
> complicated and slower and less universal.
{Shrug} I had a go at implementing this, and believe me, it's EASY!!!
Memory says it required just 11 extra lines of code, plus changes to 2
existing lines, and the resulting code worked perfectly...
However, when I offered it as a patch, I was told not to bother as the
code freeze Linus has imposed would prevent it being applied, even
though almost everybody who responded was in favour of the idea...
> 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.
{Shrug} For that to be true, it would ALSO have to be true that Linux
should never support any new hardware drivers since doing so would
"break binary compatibility" with previous versions...and Linus has
already made it quite clear that he does not accept such a premise...
> 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.
You appear to also be claiming that a purpose of UMSDOS is to cause
unnecessary confusion by mis-mangling names to indicate that files are
other than what they really are...
> It was design decision - rather good one if you ask me.
A design decision it may have been, but in my opinion, it would have
been hard to make a worse one...
> You could in the same logic accuse ext2 that it has a major bug
> since it is not a logging filesystem.
Excuse me for being so dim, butI don't see the connection between
those two claims, sorry...
Best wishes from Riley.
-
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/