OSDev.org

I am starting to try to make my filesystem but I really do not like the C:\ method and I don't quite like the /blah either so what are some alternatives that are in use/you have made up

These are the two most common (the DOS-style with drive letters and the UNIX-style with single-root and mounted filesystems), most OS projects I know adopt the latter for some reason.

Another way that I will probably go for is to use pseudo-URL-style paths, e.g. cdrom:/readme.txt or system:/systemfiles/kernel.bin. If you have a filesystem with a label field, you could use this as well: mydata:/music/dingdong.mp3.

IIRC this method was used already by AmigaOS (Solar?). Honestly, I can't think of many more practical variations, these just boil down to changing the seperating characters, writing paths backwards (like LDAP dn's) and stuff. But of course everything's up to the designer again.

cheers Joe

I'm tempted to do a combination of the two (just having both available at least). This would allow you to easily know which drive things were on by accessing with drive letters, and to use the virtual filesystem in order to (for instance) be able to easily access all of your shared stuff that would otherwise be spread across several drives.

Before MacOS X, the path separator was the colon, e.g. disk0:foo:bar.

I suppose you could use just about any other separator you pleased (pick anything that doesn't conflict with characters that can appear in file names).

AmigaOS had drive "names" - one for the physical drive (e.g. DF0: for the first floppy drive) and one for the logical media (assigned at formatting, e.g. "MyDisk:" for a given floppy). That allowed e.g. scripts to work on any floppy inserted in the first drive, or only a specific floppy.

Paths were constructed as:

DRIVE:path/to/file

An absolute path from the device root was written as

:path/to/file

"cd" was implicit, i.e. if what you typed didn't match a command but matched a path, you "cd"ed to that directory directly. Getting one directory level up was done by typing a forward slash, i.e. //somewhere was two levels up, then down into the "somewhere" directory.

Paths could be assigned "virtual" drive names, like

assign PICS: Work:path/to/my/pictures

More advanced stuff was assigning the same virtual drive name to several directories (the virtual C: drive was the equivalent to $PATH under Linux or %PATH% under Windows).

I use \bla\bla\bla for files,devices,units etc...
and bla\bla\bla for variables
I don?t see any reason to use c:
and i use \ instead of / because the second means division
in many programing languages.

From "VMS File System Internals" by Kirby McCoy, section 2.4.3:

A directory specifier has the format [name1.name2.name3....]. Each name in the list translates to a directory file name of the form name.DIR;1 in the current directory level.

As near as I can tell, this puts the filename after the closing ] of the directory specifier.

There's also a comment about the nature of file and directory naming on Files-11 on a PDP-11 (which, if memory serves, would be running RSX-11 or similar).

(I hope this comes out right, I don't see a way to escape the tag characters used by the board software.)

If you look at C and some other languages then both \ and / are used as division operators with different implications about the answer. What this has to do with path seperators I don't know, as most people aren't going to look at foo\bar in a listing and think "Oh a directory" and then at foo/bar and think "Oh a division", the difference just isn't ingrained into our minds that much, especially given the miracle of context and the use of both as paths in various places.

I was going for the AmigaOS-ish way with a few predefined paths:

~/.... for your home dir
~username/... for somebody elses home dir (only pointfull for people with admin rights)
!groupname/... for a group home dir
#progname/... for a given program directory (with #/ for the current program)
%/ for the system files

and that's all the special links. It's a little like unix in a way, you use forward slashes (since I consider the \ to be the universal escape character - which is indeed universal except for the Windows-based world where it is nonexistant and you have to hack your way around stuff you'd like to escape) and your home dir is ~.

Sidenote, you wouldn't be able to access other people's private directories but you'd be able to make ad-hoc groups for sharing files. You also have a shared dir in your private dir that others see when they use the ~ notation. Programs can only access their own directory. Shared libraries are not shared at all, but installed in each program. The file system detects which files are binary copies of each other and changes them to become copy-on-write files with a single inode. OS binaries are usable by all, but very limited (2 or 3). Loading dynamic libraries is done using inodes. That way, the DLL hell bit is completely impossible (no shared at all) but the advantage of shared DLL's is kept in (since they become the same inode, they're the same file and only loaded once). Also, cross-dependencies are completely eliminated (since you can't cross use any files).

Anyway... FYI, I believe VMS used > as path separator (>root>dir>file).

Err...

hd0:/<user>/
hd0:/<user>/app/ <<-apps folder
hd0:/<user>/desktop/ <<-user's "desktop"

The main sys is a "special user" that resides on only one hard-drive and partiton
hd0:/sys/
hd0:/sys/kernel <<-kernel folder
hd0:/sys/driver <<-plugin/driver folder
hd0:/sys/lib <<-library folder
hd0:/sys/app <<-global apps folder

I just took bits and pieces of how the SONY PSP's OS does things and added things to it to allow for a MUI
Have fun

i intend to use "/" as a separator. That's what's being used on Internet too, and the "\" is ugly to program with as it's the 'escape' character... you write a program that want to access folder\news and it suddenly try to locate a single file named "folder
ews"

i also intend to have a few "logical" locations defined by the system such as "temp:", "root:", "work:", "docs:", "home:", "conf:", "prog:", etc. The idea is that the execution environment will translate those into 'flat' path depending on the current user and program capabilities.

Typically, a program only has access to
[*] "temp:" which can be isolated from the 'temp' dir of other programs, even from the same user,
[*] "conf:" which collects environment configuration, program configuration and user preferences as a kind of "overlayed" directory (e.g. that'd be equivalent to a directory containing read-only pointers to /etc/profile.d/$PROGRAM, and read/write pointers to /home/$USER/.$PROGRAMrc, etc.
[*] "prog:" which contains the program's internal files (imported libraries, resources, plugins, whatever...)
[*] "work:" which is a 'magical place' where the system temporarily maps documents that the program will work on. The idea is that the 'file picker' dialog (for open/save) picks a document from user's locations such as "home:" or "docs:" and make it appear in the "work:" location of the requesting program for the current session only.

"root:" is the arcane filesystem for Sarah Programmatzki and Toni Administrati where you can indeed operate on everything (each program's configuration, libraries, all users's data, etc).

note that "work:" is just a prefix, of coures. What the program will open is more likely to be "work:thesis.pdf", "prog:texturez.zip/level1/tree.png", etc.

That (Sanik's) is very close to my intended design, with the exception that apps are installed to

hd0:/apps/

with just the individual configurations saved to

hd0:/users/<user>/appconfig/


[New thoughts, so responses to my old ones might not make sense, sorry]

Pype: I'm thinking of doing a kinda cut-down version of yours in addition to the above, so rather than accessing
hd0:/users/kemp/appconfig/appFoo/bar.cfg
(which implies having to determine who is logged on) you can just use
appconfig:/appFoo/bar.cfg
which will work no matter who is logged on. In this case the "drive" is used as a simple shortcut that is mapped at login time, much like network home drives.

Hey all, I'm new to the forum and this particular thread just caught my eye, so here goes. ;D

The OS I have in mind atm, Sensory[OS], would use a rather unique form of pathing.

The ramdisk is rooted at [tt]~[/tt] (which I lovingly call the "stump") and "branches" of the tree are separated with [tt]/[/tt]. The particularly unique thing is that the file system, SensoryFS, would support multiple inheritance. Each data block on the disk has a [tt]refcount[/tt]; any branch may keep a reference to any block.

This means that a file "[tt]foo.bar[/tt]" in [tt]~/my/music/videos[/tt] might also be in [tt]~/my/videos[/tt], but a different [tt]foo.bar[/tt] might exist elsewhere. If the reference to [tt]foo.bar[/tt] is deleted from [tt]~/my/music/videos[/tt], one will remain in [tt]~/my/videos[/tt], and thus the file will remain on the disk. If that reference is removed, [tt]refcount[/tt] is 0, and the file is deleted.

This type of MI might be useful, for example, in the case of shared libraries. As Candy said, they would be installed in each program directory, but why waste disk space on two copies of the same version of the same library? The possibilities are numerous (but highly abusable). I'd love to hear your thoughts on this.

Drives, etc. are mounted according to type: [tt]~/hdxy[/tt] for hard disks, [tt]~/cdxy[/tt] for cd drives, [tt]~/fdxy[/tt], floppies, etc., where x is the drive index ([tt]a[/tt], [tt]b[/tt], ...) and y is the partition index ([tt]0[/tt] [mbr], [tt]1[/tt], ...). With MI, they might also be classified in [tt]~/dev[/tt], [tt]~/dev/media[/tt], etc. Other devices (joysticks, keyboards) would be classified similarly.

Just like many systems, [tt].[/tt] = current directory and [tt]..[/tt] = parent directory. I'd be interested to hear unique suggestions for replacements, though.

This has been a (rather long-winded) two cents by the evincarofautumn.

evincarofautumn wrote: Hey all, I'm new to the forum and this particular thread just caught my eye, so here goes. ;D

Welcome to the forum.

The ramdisk is rooted at [tt]~[/tt] (which I lovingly call the "stump") and "branches" of the tree are separated with [tt]/[/tt]. The particularly unique thing is that the file system, SensoryFS, would support multiple inheritance. Each data block on the disk has a [tt]refcount[/tt]; any branch may keep a reference to any block.

This means that a file "[tt]foo.bar[/tt]" in [tt]~/my/music/videos[/tt] might also be in [tt]~/my/videos[/tt], but a different [tt]foo.bar[/tt] might exist elsewhere. If the reference to [tt]foo.bar[/tt] is deleted from [tt]~/my/music/videos[/tt], one will remain in [tt]~/my/videos[/tt], and thus the file will remain on the disk. If that reference is removed, [tt]refcount[/tt] is 0, and the file is deleted.

This type of MI might be useful, for example, in the case of shared libraries. As Candy said, they would be installed in each program directory, but why waste disk space on two copies of the same version of the same library? The possibilities are numerous (but highly abusable). I'd love to hear your thoughts on this.

You are thinking of making each copy of the file a copy-on-write file (like my design) or are you thinking of making each entry the same file? If so, then your design is equal to Linux (or unix in general) with hard links, possibly except that your files have one name that you use in multiple directories. Note that this carries a performance penalty when renaming it, since you must check all directories its in for collisions.

Also, will you allow it for directories? That gives a problem when you link a directory into itself, creating a loop, and even more when you subsequently delete the first (entry of loop) entry. You'd be stuck with a directory loop that would never be freed, because it always pointed to itself for use. You can't solve this by not incrementing the refcount if it's pointing to itself, since you can do multi-directory loops. You'd have to check the entire subtree.

Also, will you allow it for directories? That gives a problem when you link a directory into itself, creating a loop, and even more when you subsequently delete the first (entry of loop) entry. You'd be stuck with a directory loop that would never be freed, because it always pointed to itself for use.

I realise that there could be a problem with circular references if a directory kept a reference to itself. The thing that would prevent such circular references from becoming a problem is that data blocks keep a list of references to the blocks that reference them.

(As it is likely that the file is not in more than a few directories, this can't have too much overhead in terms of disk space. Only a few bytes are required for a pointer to a block, anyway.)

If the only reference to a block is itself (i.e. the [tt].[/tt] entry), it can be safely deleted without breaking anybody's pointers. That's not to say that files couldn't be deleted by the user while they still have references: all references would be removed and patched before the block is wiped. This solves the problem of having to check too many directories when deleting folders.

Thus the user would be presented with several options for deleting a file:

• delete this instance of [tt]foo.bar[/tt] (in [tt]~/my/videos[/tt])
• delete all instances of [tt]foo.bar[/tt]
• delete [tt]foo.bar[/tt] from... >
  • [tt]~/my/videos[/tt]
  • [tt]~/my/music/videos[/tt]

And references would be created/patched/deleted accordingly. "moving" a file to another directory is accomplished by manipulating references, so moving time is independent of file size (unless the file is being moved across volumes). "copying" would involve duplicating the contents of a file to a new block, while "cloning" would simply create a new reference.

This could end up being pointer hell for me to code, but I think this sort of thing has some potential.

your design is equal to Linux (or unix in general) with hard links

I'd say that it's similar. One difference, as you pointed out, is that a file and its name are tied more closely together. The main difference, however, is that a "link" and a "file" block are very different things from one another in SensoryFS: files can contain data, while links can contain only a single reference.