OSDev.org

How should the file system be designed? How should file search functions work, file open, read, write?

This is my scenario:

-fopen() gets a number on which fprintf() fclose() all work on. the vfs (virtual file system - is this the name of the fs which can mount/unmout?) has a list of these numbers.

-fread() (or something to read the file) sends how much bytes it wants. somebody allocates dynamic memory for that size, in which the bytes are; an internal offset counter of the file changes; the kernel maps the ptr into task adress space and givcs the adress. If requested size is bigger, than there is left before eof, an error occurs.

-fclose() flushes all buffers.. I don't know how a buffer should work.

How would you design these funcs?

Cheers,
Adrian.

I think you would allocate mem to *UPLOAD* the data. Then do f_close to free up the memory.

1. No, I do not believe in communism neither as it has been handled by stalin and co. for they haven't read karl marx ideology correctly nor as it IS handled today in the last remnants of communistic regimes (tyrannis is a better expression for them)

2. fopen acquires a file descriptor which is stored in the file system service structures and which keeps several info about the opened file (attributes length and so forth...

3. buffers: some space for a process to dump/save data on for later use by an other process... buffers of course get flushed on several occasions. say printf puts something in the buffer for output and the process exits ... the exit procedure should close the console file and flush the associated buffers . so the user gets the last output ot the process ere it has crapped out.

stay safe

1. No, I do not believe in communism

Me neither

What about searching for files - I would give away a total listing of the directory to the user task, and some user funcions would search it for specific matches.

Cheers,
Adrian.

Adek336 wrote:What about searching for files - I would give away a total listing of the directory to the user task, and some user funcions would search it for specific matches.

That's the Posix opendir/readdir way, and it generally works. You could extend this to the Win32 way, and do the filtering at the file system layer. There's no difference when listing local directories, but it really speeds things up over a network. Consider obtaining a listing of an FTP directory containing 10,000 ZIP files and 1 TXT file, and you want *.TXT. opendir would retrieve all the file names and filter out all but one, whereas FindFirstFile would ask the server for *.TXT.

you can push tim's proposition to a larger extend, sending the Directory object a pattern that files must match, for instance or if you prefer

In most situation, it just means less communication between filesystem and user space, and in some case it could also take advantages of existing indexes, etc. However, it requires execution of user-provided "code" into server space, which is certainly not a trivial thing to implement securely ...

Ah! So the Directory.find returns a directory listing with the matches yes? I was afraid I had to implement a DOS-like findfirst/next.

BTW What rules a filename has to obey - max length 256 bytes, are there any characters which are not allowed in it? I can think of one, "/".

Adek336 wrote: BTW What rules a filename has to obey - max length 256 bytes, are there any characters which are not allowed in it? I can think of one, "/".

That depends on the FS you implement. if you're creating YourFS, the maximum length is whatever you want (or can) - they are usually arbitrary and decided for convenience only (as for the "maximum path length")