> > 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 play with SETVER without reading big WARNING about it (see below).
It did work for me in 5.0. In which mode did you run it ? I cannot see how
it could caused any corruption (as it by default modifies only exec int 21h
functions), unless you used that option that made it propagate in other
functions (findfirst/findlast, delete, etc). Which than did whatever it
should (if you tell it to del *.exe, it did so in all dirs. Which is what is
was supposed to do).
[this is begining to be offtopic...]
> >> 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...
>
> 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
Can't talk about PC-LAN, but LANTASTIC here never had those probs.
Especially with SD/DEFRAG, I cannot see how it could ever do anything on
network disk, unless your network provided INT 25h/26h (raw cluster
read/write, if I recall interrupt numbers correctly), which I never saw any
PC network to do, and which SD/DEFRAG requires to run at all.
> (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...
Never used PC-LAN, so I can't comment on that. If it did that, than it
obviously was not MS-DOS FAT compatibile, and would not get a 'Compatibile
with MS-DOS' sticker (had they been invented before win95; stickers that 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...
You did read HELP for SETVER, didn't you ? Which warns you of EXACTLY those
consequences. Fooling things that they are running under something they are
not is never a good idea unless you know EXACTLY what you are doing.
Ever tried driving a card while thinking you are in soft, warm bad at home?
Well, DON'T. Especially if car instructions warn you not to do it.
> > 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...
I'm not trying to use UNIX semantics in MSDOS. I'm trying to use it in
Linux, using MSDOS storage space, without DESTROYING it, and with maximum
flexibility.
It is extension for MSDOS filesystem. As long as there is a need for MSDOS
filesystem (which is NOT compatibile with VFAT, whatever you say) there will
be need for UMSDOS instead of UVFAT.
> I can't speak for the 2.1 kernels, but it was definately present in
> 2.0.34, the last one I checked...
I've only taken maintenance after 2.1.x dentries change, so I wouldn't know
about that, really. It seems to work ok in 2.1.x kernels. If it could try
and report any problems with cases you had, it would be nice.
> >> *.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.
Oh... so you never run DOS or Win 3.1x program under Win95 ?
Some of so-called 'win95' programs also use old 8.3 interface, and only show
me short names. And they are mangled simular to umsdos -- without nice
translations which you show above.
> 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...
I sincerly doubt that micro$oft had anything to do with alternative naming
for .tar.* archives.
> >> *.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...
You could of tried to sneak it in via maintainer channels :-)
However, since it in this case breaks compatibility for very little reason,
it wouldn't go in anyway.
There is a way to do it, though.
Change EMD file format so it contains both short and long file name (instead
of just a long file name which uses known mangling routing to get short
one). Then you could change mangling strategy in every kernel patch without
doing any damage.
It might be feasible, as umsdos_dirent structure somewhat provides for
extending it by shortening maximum filename length. Very long filenames will
make chaos then, though. Project for 2.3 if you are interested in it.
Which also would be time for UVFAT, if anybody is interested in it. I think
however, that all data should be kept in EMD file as it is with current
UMSDOS, and only duplicates maintained in UVFAT... That should not be very
hard to do.
That is, of course, unless someone pops with nice idea how to stack UNIX
semantics on any local (and/or remote?) filesystem, which would be
particulary nice.
> > 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 can not follow you reasoning here. Adding new hardware driver does not
break anything. It may or may not work for persons having that hardware, but
it will in no way affect other people.
But if adding for example logging support to ext2 driver would make all
files using triple-indirect-blocks to break, that change would have a very
hard time to get in, IMHO.
> > 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...
No. But I DO think that destroying filesystems of so far many happy users
just so few other users in some cases somethimes may see some things look
little nicer (for them) is NO-OP. Propose me a way to do it without risking
already existing data, and I will include it.
> > 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...
If you ask me again - it was good decision. It opted for no-exceptions,
knowing if few of them went in, it would have to change it again for next
few exceptions. And changing the mangling strategy breaks ALL curently
existing filesystems using that driver, and it a bad thing. If it made
exceptions for few extensions (like .tar.gz -> .tgz, .tar.z -> .taz) first
next change (like .tar.bz2 -> .tbz) would break all existing filesystems.
It is absolutly non-acceptible, as price to pay is way to much for extremly
minor improvement it makes in some cases. Every time new nice format with
more than 3 letter extension pops up, you would have do destroy all umsdos
filesystems in use. Surely you do see that is BAD THING (tm).
If making change once, destroying compatibility, would yield some noticable
improvement (and avoid destroying compatibility after few months again), I
would consider doing it (after providing conversion utility, of course). In
this case, well, I do not see the case.
Just to make another example, of design decision which opted for
'yes-we-want-few-exceptions'. It was (is?) MSDOS conv=auto feature, which
had hard-coded list of what was considered binary, and list was not
regularry updated, which make copying for example .mp3 files from MSDOS to
ext2 partition break beyond repair. It is much easier to fix, as changing it
does not break any existing data, but saves further data from being
destroyed.
-- 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/