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
