OSDev.org

Do you think the path of the current dir should be stored, by the vfs, shell, terminal, on a per process bais etc. This seems necessary to have programs which edit a "myfile.abc" relative to eg. "/bub/builder".

Cheers,
Adrian.

I don't really see what the vfs, shell, or terminal would have to do with the current directory.  In UNIX, each process has its own current directory and it keeps track of it itself.

that seems fairly reasonable. one current directory for the whole system would have some cons

I like the idea of passing the current directory to children processes when you shell them. Children will inherit the current directory of thier parent.

So if the user uses the CLI to navigate to "/dir/example/" and runs a command "LIST" from there, CLI will pass the current directoy to LIST before running it. If list feels the need to spawn its own children processes, it would pass the directory to them as well.

The question is: Should child processes be able to change thier parent's current directory? If so, "CD" commands can be exported to seperate executables (which I prefer) but processes have to worry about "backing up" the path before shelling children to prevent unpredictable state modifications.

Which ever methods you choose, I think its best to make state information like the current directory process-specific.

Personally, I'm giving each process a list of "properties" in a process control structure. The parent process can either preform a simple EXEC/FORK or it can LOAD the program manually and read/write its properties prior to running it. When the child quits, the parent can either ignore final properties or it can read them back as extended return codes, making whatever state changes it needs.

These properties are extensible and can be defined for each process arbitrarily. If a process doesn't need a "Current Directory" property, it doesn't have to have one. On the other hand, if a process is a web browser and needs a "Current Webpage" property it can have one. This integrates well into my OS which uses the "everything is a file" paradym. All files can have such arbitrary properties which are stored by the filesystem and are accessable by the VFS layer.

For example, a file manager can handle icon-drags within the same folder by modifying the dragged icon's "Graphical Matrix Position" property to a new set of "x,y" coordinates. These properties can be either stored on the filesystem seperatly or derived by the state of the file. For example, an image can have a derived, read-only "Width" property if some process hooks into the VFS layer to provide this data. The filesystem itself can also transmit derived properties such as "File Size" or "isDirectory".

I have actually developed an extensive property management system for the VFS which deals with issues such as inheritance, access rights, initialization and even per-file event handlers like "onDelete" or "onOpen" which can be linked to low level service calls or even envirnment scripts.

Anyways...sorry for the ramble. )

-Robert

Something like "inherited dirs" sounds nice. Once you start a process, it inherits its current dir from the parent process (OS or other program). I recommend that it does not change the path of the parent process on return, but returns a structure with process information in the same way it was passed when the process was started. This way the parent process gets information about dir changes without the need to backup anything (and it avoids chaos when it runs several child processes).

In fact, one current directory for the whole system would be chaos if there were any form of multitasking.  A program couldn't gaurentee that its own current directory wouldn't change all of a sudden.  A program that creates files at several points in its execution would end up leaving a trail of files all over the system.