Messages in this thread | | | Date | Fri, 13 Nov 1998 01:41:57 +0100 | From | Matija Nalis <> | Subject | Re: Fixing UMSDOS |
| |
On Thu, Nov 12, 1998 at 01:49:39PM +0000, Riley Williams wrote:
> > 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/
| |