Hi All,

I've done quite a bit of searching and surprisingly haven't found anything.
Is anyone aware of an Open Source (or just free) implementation of a
filesystem in a file?

I'm thinking something along the lines of a library that provides filesystem
type access to a file.

For example

FS *hey = fs_mount("/tmp/my.filesystem");

FS_FILE *file = fs_open("/subdir/hey", O_RDWR);

fs_read(buf, sizeof(buf), file);

fs_umount(file);

Has anyone seen anything like this previously? I'm kind of surprised since
it seems like the kind of thing that would have been done before?

Thanks,
Shaun

[ Post a follow-up to this message ]

"Shaun Clowes" <delius@no.spam.for.me.progsoc.org> writes:

> Hi All,
>
> I've done quite a bit of searching and surprisingly haven't found anything
.
> Is anyone aware of an Open Source (or just free) implementation of a
> filesystem in a file?
>
> I'm thinking something along the lines of a library that provides filesyst
em
> type access to a file.
>
> For example
>
> FS *hey = fs_mount("/tmp/my.filesystem");
>
> FS_FILE *file = fs_open("/subdir/hey", O_RDWR);
>
> fs_read(buf, sizeof(buf), file);
>
> fs_umount(file);
>
> Has anyone seen anything like this previously? I'm kind of surprised since
> it seems like the kind of thing that would have been done before?

This is done everyday with Linux:

dd if=/dev/zero of=/tmp/fs_file bs=1k count=20k
mke2fs /tmp/fs_file
mount -o loop /tmp/fs_file /mnt
cp some_file /mnt
umount /mnt

--
__Pascal Bourguignon__                     http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

[ Post a follow-up to this message ]

In article <zdzWc.164$HO4.2113@nnrp1.ozemail.com.au>, Shaun Clowes wrote:
>
> Hi All,
>
> I've done quite a bit of searching and surprisingly haven't found anything
.
> Is anyone aware of an Open Source (or just free) implementation of a
> filesystem in a file?
...
>
> Has anyone seen anything like this previously? I'm kind of surprised since
> it seems like the kind of thing that would have been done before?
It's been done many times in various forms, seems common particulary
in games.
http://www.feep.net/libtar/
http://razip.sourceforge.net/
http://icculus.org/physfs/

[ Post a follow-up to this message ]

"Pascal Bourguignon" <spam@mouse-potato.com> wrote in message
news:874qmt136o.fsf@thalassa.informatimago.com...
> "Shaun Clowes" <delius@no.spam.for.me.progsoc.org> writes: 
anything.[vbcol=seagreen] 
filesystem[vbcol=seagreen] 
...[vbcol=seagreen] 
since[vbcol=seagreen] 
>
> This is done everyday with Linux:
>
>     dd if=/dev/zero of=/tmp/fs_file bs=1k count=20k
>     mke2fs /tmp/fs_file
>     mount -o loop /tmp/fs_file /mnt
>     cp some_file /mnt
>     umount /mnt

Yeah, sorry, I should have included more detail in my message body from the
subject line, I need a completely userland implementation (i.e a loopback
filesystem isn't possible in my case).

Cheers,
Shaun

[ Post a follow-up to this message ]

"Nils O. Selåsdal" <noselasd@Utel.no> wrote in message
news:slrncilqlv.o6n.noselasd@nos-rh.utelsystems.local...
> In article <zdzWc.164$HO4.2113@nnrp1.ozemail.com.au>, Shaun Clowes wrote: 
anything.[vbcol=seagreen] 
> ... 
since[vbcol=seagreen] 
> It's been done many times in various forms, seems common particulary
> in games.
> http://www.feep.net/libtar/
> http://razip.sourceforge.net/
> http://icculus.org/physfs/

While all of these are interesting they all suffer from the same problem,
the write support is limited or non existant. The thing is, a filesystem is
simply a layer on top of a set of blocks, it's interesting that no-one has
ported a complete filesystem (e.g ext2, ufs, ufs2) to a userland library so
that it could be run on top of an arbitrary block layer (e.g a simple block
layer on top of a file).

Cheers,
Shaun

[ Post a follow-up to this message ]

"Shaun Clowes" <delius@no.spam.for.me.progsoc.org> wrote in message
news:COPWc.1$0S5.192@nnrp1.ozemail.com.au...
>
> "Nils O. Selåsdal" <noselasd@Utel.no> wrote in message
> news:slrncilqlv.o6n.noselasd@nos-rh.utelsystems.local... 
wrote:[vbcol=seagreen] 
> anything. 
> since 
>
> While all of these are interesting they all suffer from the same problem,
> the write support is limited or non existant. The thing is, a filesystem
is
> simply a layer on top of a set of blocks, it's interesting that no-one has
> ported a complete filesystem (e.g ext2, ufs, ufs2) to a userland library
so
> that it could be run on top of an arbitrary block layer (e.g a simple
block
> layer on top of a file).
>

Let me try to understand what you want because it sounds to me -- at least
initially -- as though there are some contradictory or poorly formed
requirements being hinted at here.  Tell me if this is something like your
goal:

1.  A program somewhere, run one time (per "filesystem") creates a "blank",
"formatted" filesystem by writing a (large) file with the appropriate
structures.

2.  Another program -- probably running like a daemon -- accepts some kind
of IPC requests to perform typical filesystem operations within one of these
files:  "open", "create", "read", "write", "seek", "tell" [anything miss
ing]
and simulates the operation by reading from or writing to the requested
file.

3.  One or more user programs which interact with this centralized
intelligence so that the whole emulates a multitasking OS running
user-programs against the filesystem(s).

OR

1.  A library that's linkable into a user-program which performs the actions
1 & 3 above but only for the program in which it's resident and then
simulates a single or multitasking OS depending on the single or multiple
threading nature of the single program

Since I don't know which you want, I can't even begin to decide whether it's
been done before or not.  Please clarify.

Norm

[ Post a follow-up to this message ]

"Shaun Clowes" <delius@no.spam.for.me.progsoc.org> writes:
 
.
.[vbcol=seagreen]
> [...] I need a completely userland implementation

The "mtools" package is a complete userland implementation of the
dos/vfat filesystem(s).  I've used it in a number of projects,
generally when I preferred to have filesystem problems crash a process
instead of the kernel.

You didn't say if you needed a Unix-like filesystem or just something
vaguely filesystem-like; vfat of course only qualifies for the latter.


Mtools is not, mind you, a library; at least it wasn't last year.
If I remember right, the KDE project's file browser includes an
mtools-backed module (suitable for usb keys, flash readers, etc).
This might represent a librarified mtools interface, but it may well
be in C++ or require some other displeasing infrastructure.

--
Grant Taylor
Embedded Linux Consultant
http://www.picante.com/

[ Post a follow-up to this message ]

Grant Taylor <gtaylor+cup_abdig082504@picante.com> writes:

> The "mtools" package is a complete userland implementation of the
> dos/vfat filesystem(s).

Which reminds me of a few tidbits I forgot to mention...

There is a similar package for the Linux ext2 filesystem called
e2fsimage.  Actually, there are several programs like this, but this
is the first one that popped up when I went looking.

The e2fsck, debugfs, and Linux dump programs are based upon a partial
library implementation of the ext2 filesystem called libext2fs.  Key
metadata structures and some utility routines are provided.  In the
past year or two this may have been fleshed out into a more complete
implementation (two years ago I implemented a handful of missing
features in debugfs so that I could do essentially what e2fsimage
does).  The e2fsimage package, and workalikes, are probably all based
on this library.

I would be surprised if there weren't many other examples out there.

--
Grant Taylor
Embedded Linux Consultant
http://www.picante.com/

[ Post a follow-up to this message ]