Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #9430

Re: Representing a hierarchical file system

Show all headers | View raw

On Mon, 15 Aug 2011 12:24:56 +0200, jacob navia wrote:

> Within the context of the containers library I would like to be able to
> represent a file system, i.e. directories and files within a tree
> structure.

> For instance:
> 
> typedef struct tagFile{
> 	char *Name;
> 	size_t size;
> 	FileTime last_save;
> } file;
> 
> typedef struct tagDirectory {
> 	char *Name;
> 	size_t NumberOfChildren;
> 	struct tagDirectory **Subdirs;
> 	size_t NumberOfFiles;
> 	file **Files;
> }Directory;

This is quite different to typical filesystems.

E.g. on Unix, you have the inode, which contains the size,
owner, permissions, modified/accessed times, etc, plus the list of blocks
containing the data. Note that the inode /doesn't/ contain the name. Every
file, directory, symlink and device has (or, really, is) an inode. The
stat() call basically returns a copy of the inode, minus information which
is "internal" (e.g. the list of blocks).

Then you have directories, where the data consists of a mapping from names
to inode numbers. On early systems, a directory was simply a list of
<name,inode#> pairs. Modern systems use e.g. a btree to facilitate random
access (looking up a specific name in a directory is far more common than
enumerating the contents of a directory).

DOS' FAT filesystem places everything into the directory, so rather than
just a name and an inode number, the entire "inode" is included as part of
the directory entry. The main drawback compared to Unix is you can't have
hard links (multiple directory entries referring to the same inode
number). Also, on VFAT and NTFS, filenames are Unicode wide strings, not
byte strings. The inefficiencies of FAT are circumvented by building more
efficient representations in memory.

Assuming that you're not trying to implement a real filesystem, I'd
suggest replacing the file and directory structures with a common
"node" structure which includes a union member for the
file/directory/other parts. For a directory, the data would be a map
(btree, hashtable, etc) with names as keys and either nodes or references
(pointers, indices) to nodes. Separate maps for files and subdirectories
may or may not be a good idea.

If you are trying to implement a real filesystem, you need to figure out
how to make modifications efficiently (i.e. not contiguous blocks which
need to be realloc()d whenever something changes).

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Representing a hierarchical file system jacob navia <jacob@spamsink.net> - 2011-08-15 12:24 +0200
  Re: Representing a hierarchical file system Ian Collins <ian-news@hotmail.com> - 2011-08-15 22:36 +1200
    Re: Representing a hierarchical file system jacob navia <jacob@spamsink.net> - 2011-08-15 19:43 +0200
  Re: Representing a hierarchical file system Keith Thompson <kst-u@mib.org> - 2011-08-15 09:23 -0700
    Re: Representing a hierarchical file system David Thompson <dave.thompson2@verizon.net> - 2011-08-21 03:22 -0400
  Re: Representing a hierarchical file system Nobody <nobody@nowhere.com> - 2011-08-15 18:02 +0100
    Re: Representing a hierarchical file system jacob navia <jacob@spamsink.net> - 2011-08-15 19:44 +0200
  Re: Representing a hierarchical file system China Blue Tip Wrench <chine.bleu@yahoo.com> - 2011-08-15 10:35 -0700
    Re: Representing a hierarchical file system jacob navia <jacob@spamsink.net> - 2011-08-15 19:46 +0200
      Re: Representing a hierarchical file system "Heinrich Wolf" <invalid@invalid.invalid> - 2011-08-15 20:31 +0200
      Re: Representing a hierarchical file system Ian Collins <ian-news@hotmail.com> - 2011-08-16 08:32 +1200
      Re: Representing a hierarchical file system Nobody <nobody@nowhere.com> - 2011-08-16 11:45 +0100
        Re: Representing a hierarchical file system BGB <cr88192@hotmail.com> - 2011-08-16 04:00 -0700

csiph-web