now, what is a file?

a file is a string of bytes with a name and a date of creation, and a location.

it is a muldimensional object then.

for a CVS tool, a file is mainly an entity with an identifier, and a set of updates.

then, now, what can be made to have a very good file system?

an ID (UUID for example, but better of course, cause we just made better things, if not, don't do anything at all and return to holidays), and this id is an entry connecting to the current state of the document, and it's history.

but make it simple please, nobody wants to deal with complex stuff where it can be simple.

then, the version control should just be an overlay, or a plugin, or something like this. an option. This option to have a version control is one option into many others. theses options should be stackable, treeable, modifiable, and so on.

an other option can be the cryptography layer, the connection to a software , a class, or anything. it can also be a linkage, a stringage of documents, a machine, an user, and so on. anything can be optionnal, but the file itself is not an option.

this file is then the element we need to handle.

what is a file? really?

it is a string of bytes, somewhere.
even the meta data of a file is an option if we consider this design.

then, a file is an item described by it's location, its size and that's all.
if we need overlay, we should then create another structure, like filemeta.

filemeta will then be a set of metadata used to describe the file as a document.

for example, filemeta will have a name, a datetime, and a pointer to a fileitem.

now if we need crypto or anything, we should make it a fileitem.
this fileitem is just a set of the cryptotool flag and a pointer to the fileitem.

what is now to consider is the fact that to exploit a crypted file, we also need to get the file location and size. these datas are given by the file structure. the file tool will then scan the tree of items to get theses data from the corresponding item.

means that tools to handle files should work only on theirs datas, and ignore the datas from others elements from the tree.

this feature is transparent with fool due to the .call pointer at the beining of every items.

the stacking and pluging feature is also transparent in the fool design, then, this speach end there, and just tell a file is a name, and a pointer to a fptr.


file:
.call=0
.fptr=4
.name=8


then a filemeta is

filemeta:
.call=0
.file=4
.datetime=8
.option=12


.option there is a plugin or a tree of plugin. this item will then be used to pipeline the .file item.


[old]
as the problem is not simple ( create new objects in the structure) i plan on the basic functions:

DISK
file

will read the drive and copy the bytes in the ram. or write from ram to drive.

but...

drives are mainly fixed size and will not change during os running.
the disk structure i use for the moment is big:

needs to reserve 24 bytes for all disk objects.
the idea to correct the problem will be to reserve only one drive access object for each drives.
the applications will ask the system to r/w the device via the only structure for hte drive or application.
no need to make 10 objects for all drive accesses.
only one for all drive accesses from all application.

to do so, a little object is needed.
the minimal unit of data to lacate and quantifies a file.
LBA(32) + bytes(32)=64. to start.
a 4 gigabytes file is very big for me.




the problem is:


apparentlly it is a big waste of memory to use them for each disk objects, and a big waste of ressources to build them.

as stated above, this object, drive geometry at least, will be globalised.



let see the procedure itself:



as you can see, it use the BIOS int13h and for all disk operation, it will build the disk size field using BIOS drive ID.
but, it can be avoided by using a global drive identification for exemple.
this ID, where to put it?

then, it reloop the problem somewhere in the kernel, if the kernel is really modular, it will not have a fixed location for drives IDs.

th emodularity will be killed a little.
for example, an application that will access the drives will have it's own drive context, but only one time, at a specified location.
for example the application will enter with [desk], and the related drive context is [drive]

desk as ram, and drive, as hard disks and floppies.

finally, i adopt this sheme previouslly aborded.
it works very well, need some bugfix ( very meticulous work).
bug's are theses:

if you don't mov value at [esi+disk.drv] with the right dl, it don't work at all.

3 essentials functions use disk structure.
reboot, to read the bootsector and jump to it at 0:7c00h, need plain dos ( not tested).

bootcopy, to copy the bootsector on a drive

install, to install the current settings on a drive.

be carefull, use only with test drives.

it don't works when i type:
install 128 <enter>
bootcopy 128 <enter>
reboot 128 <enter>

but it has worked only one time with:
x <enter>
and don't hav the time to test more tonight...

now, f.disk uses a pointer to a fptr to access memory.
and the best, it uses LBA instead of CHS, even for floppy.

it gives this structure:

to do a drive id,call an empty disk item (.ptr=0)
.ptr îs a 32bit offset in current address space (org ???)
id ptr=0, then, it is not a valid pointer, and it ends.

i like this '0' value.


next step, link it to a file system.
the first attempt is in bootwriter06

it uses DOS int21h

3Dh, 3Fh, 3Eh.
open, read, close
the dos handle is only used inside this linear stream.

then,it limits my needs from file system to that:

fileread:
.call=0
.ptr=4 ; same structure as one pointed to by disk.
.name=8 ; ascci path and name of the file, a command line parameter for example.
.handle ; value returned by dos, but not used by fool.

knowing theses needs, it is easy to do a singular structure around fptr

effectivelly, fptr have all the chances to become a file system structure.

fptr:
.off=0
.seg=2
.size=4

.size is used by disk and updated by fileread.

if you want to read 321 bytes from a 32 bytes file, it will be usefull.

if you wan to set the file size to a sector boundary.
etc etc.

a file would be represented by this on the disk:



there, you see it can be possible to set a ram location for the file.
why?
just to show it is still in ram,at the fptr location.
if fptr = 0, then, the file is on the drive, or nowhere.
this value is not modified on the drive. only moded in ram.
the cached folders will contain the xfiles, xfiles are only file descriptors.
like the DOS handle

then, a file in ram will be descripted by it's descriptor in folder (in ram too). if not in ram, then, read it from drive. and update fptr.


file access can be only with the 'path/folder/file' style.
but after loading, the path is converted into a fptr.

and this fptr is a DOS-like handle.
a little more fool.


to update fptr, i need memory management .