Hi,
Eric Auer wrote:
Hi, I tried to check SFT compatibility of FreeDOS, quick conclusion:
sft_dcb is never accessed
sft_stclust is never accessed
sft_relclust is never accessed
sft_cuclust is never accessed
sft_dirdlust (sic!) is never accessed
sft_diridx is never accessed
sft_bshare is never accessed
sft_ifsptr is never accessed (nor initialized to 0?)
Before 2k I was going to move the fnode stuff over to stf. I got sick and
forgot most of the things I intended to do to help move FD out of the stone
age DOS (v2.xx) to something like M$'ish DOS. To this day I still do not
remember. All I have was notes and print outs with writings.
It went something like this,
Phase I, integrate redirection support.
Phase II, implement a simple himem and UMB support.
Phase III, fix sft tables and code.
Is that correct? I think SFT-messing programs like Windoze will not be
happy in particular about all those uninitialized cluster values, the
missing DCB pointer, and missing dir entry info. The share / ifs stuff
is probably less interesting or set by SHARE / IFSdrivers directly,
without kernel interaction.
Each SFT uses some header with size info and link pointer, and tools
like FILES.COM or Windoze will just search for the last SFT and add
extra SFTs - how will FreeDOS react? I think this will create SFT slots
for which no fnodes exist.
It would be better to go full SFT and not worry about fnodes.
Next point are the fnodes themselves:
f_count, f_mode, f_flags, f_diroff, f_dirstart, f_offset, f_cluster
and f_cluster_offset all seem to have exact equivalents in the SFT
slot structure. Am I misunderstanding something here or could we just
throw away half of the f_node fields by using the SFT slot fields
instead???
,,,same thing here too.
There would be still some remaining f_node fields, but they would be
not much more than a copy of the raw directory image data (f_dir) and
a pointer to the DPB for the file (f_dpb).
I must be misunderstanding something here - if removing f_nodes would
be so easy (in terms of: replace fields by very equivalent SFT fields),
then why did we have that big project with "near fnodes" instead of
just throwing away the fnodes altogether?
Good question!
So please tell me where the big hidden caveat is lurking.
Thanks for reading this maso mail ;-).
Eric
W/O going into great detail, it does look like you'r on the right track.
PS: If a DCB and a DPB are the same (?), the only left over f_node
purpose would be holding a copy of the raw directory entry of the file.
That could be guarded by something like storing a checksum of the
starting cluster and filename in the fnode, and re-read the directory
entry if the SFT slot has changed unexpectedly (a warning could be
shown if the SFT slot has changed unexpectedly when FreeDOS would like
to write back the directory entry to disk).
PPS: A few bits of f_flags might differ from sft_flags bits.
[This mail is based on browsing the SF.net 2035 sources, no CVS updates...]
Start rewriting!
Good Luck,
James
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel