Mail Archives: opendos/1997/04/16/05:12:41
Once upon a time (on 15 Apr 97 at 16:33) Matthias Paul said:
> > > Using some more 'intelligent' algorithms
> > > also decoding the context of an entry, it should be possible to
> > It is possible to tell the LFN from SFN entry by just looking at
> > the starting cluster field which in LFN is always zero. To
> > confirm we're dealing with LFN it is also possible to check the
> > attributes of an entry: 0xFF for LFN.
^^^^should be 0x0F of course ;-)
>
> Looking at a cluster of zero is a rather nice idea, but probably won't work
> any more with FAT32 partitions, where the start-cluster word is only the
We don't have to worry about that IMHO. I suppose that what's going to happen
is that OpenDOS will have several installable drivers for several supported
file systems. Since FAT32 is not really FAT we used to know and love ;-) we
don't have to bother with this kind of compatibility. Introducing support for
*all* file systems in the FS utilities doesn't make sense - the user will
probably use one, at most two, file systems at a time. Therefore we should
rather gorup similar file systems and create common support for all these.
Such a solution in case of original, and fairly compatible, DOS file systems
would include FAT12, FAT16, VFAT with all variations of these supported by
all the OSes we're interested in. That way the software doesn't get too
complicated and everything becomes much easier.
> low-word of the actual start cluster. We'd need at least some more
> plausibility checks. Unfortunately, a set volume attribut is also used by
> DELWATCH... If we cannot develop some nice fitting decoding algorithms for
> the several combinations of usage, we might need to modify DELWATCH, rather
> than 'standard' LFNs. Changing DELWATCH might also break UNDELETE,
I agree. If we are to modify anything, let's modify something we can control.
I was thinking about using the "reserved" dirent spots for storing link
information. It would be fairly easy to create support for unix-like links
on the FAT system. And we all know advantages of symbolic links!
> DELPURGE, CHKDSK, and the file-io in the kernel. For future OpenDOS issues,
> we should at least introduce a flag/type byte in the directory entry,
> describing the future usage of a directory entry under OpenDOS, and the
> kernel and all affected utilities would need several case decisions for
> 'old' and 'new' variants of usage. Doing so, we'd need to 'guess' the
> actual usage of an entry only for old entries not using this type byte...
Why don't we take the LFN approach? Every "extended" (eg. having "extended"
attribute set) dirent would be *followed* by another one with all the
additional information we need. This would be much easier to implement -
minor changes to all software just to recognize the new additional type of
dirent. Opinions?
> > I've just started to write a TSR to provide LFN support. As soon as
> > it has some shape, I will make it available for all to review and
> > improve.
>
> Hey, now that's good news!!! ;-)
> Are you utilizing DPMS?
Yes. I'm writing the software in NASM to make it the smallest possible. It
will hook int 0x21 to provide support for the VFAT LFN extended functions (it
*will not* fake Windows95 is there - programs which rely on this fact to
check for LFN support are buggy - they should detect LFN support by looking
at the return value from any of LFN extended functions) and also will hook
int 0x2F to provide several custom interfaces.
I am also thinking about writing a .SYS driver to mount Linux ex2fs
partitions. I have already d/loaded ex2tools and some other packages and I'm
trying to build a library of ex2fs access functions. I would appreciate any
help in this task - it takes much time to create a library of such functions,
especially when it is going to be used from an assembler program. The library
may be written in C, that's not a problem, but it has to be portable among
compilers and it cannot use the standard C libraries - they *all* rely on
startup code which is not going to work in an asm proggy.
> > > More detailed info on the usage of these structures can be found in
> > > NWDOSTIP.TXT (from my MPDOSTIP.ZIP) and in Ralf Brown's interrupt
> > > list INTER53+.
> > Great info! Thanx!
>
> :-)
>
> Well, INTER53 still does not cover LFN in full details, but INTER54
> or INTER55 should become much better... ;-) Also, I'm just writing
> new LFN infos down for Ralf, you'll get a CC: if ready for release.
Great, thanx!
> > P.S. Could you send me MPDOSTIP.ZIP by email? I was unable to
> > ftpsearch it anywhere??
> Opps, it is located on several FTP servers in Germany, namely
> the three sites directly supported by me are:
>
> ftp://ftp.rhrz.uni-bonn.de/
> ftp://ftp.uni-stuttgart.de/
> ftp://ftp.leo.org/ also via http://www.leo.org/
I haven't tried these - I will go there today.
> I would recommend you looking at my web-page - see the URL in my
> signature (I thought, I had mentioned this serveral times in the
> past). There you can find MPDOSTIP.ZIP and several other tools,
> some of them especially written for DR DOS, Novell DOS, and
> OpenDOS. Also included are links to other OpenDOS info providers
> and related programs.
I did, but Netscape didn't d/load all of the page - the part with actual
links was missing - I was unable to get to them in any way. Even with
WebFetch-like tools.
> Of course, if you cannot get the file from there (for what reasons
> ever), I could also send it to you by email, but does your in-box
> allow for mega-bytes of mails? (The current version of MPDOSTIP.ZIP
> as of 1997-04-14 is ca. 525KB zipped...) However, if you run into
> any problems when downloading my files, please email me again, and
> I will sure help you.
I will try to get the files today again. I'll get back to you if I have any
problems.
==================================================
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of
reasons why.
Yesterday starts tommorow, tommorow starts today
And the problems seem to be we're picking up the
pieces of a ricochet...
- Raw text -