image as an FS: HOWTO?

[Ivan Shmakov]

Suppose that I need to develop a "few files only" application
(so to make it convenient to pass around for the users of the
systems lacking decent package management) based on an existing
"way too many files to install manually" one (written in C.)

My idea is that the files would be: the immutable data file, the
mutable data file, and the executable binary; though I'm not yet
sure if I'd need to keep all the working data in a single file.

Then, the immutable data file could be pretty much any kind of
an archive, as long as it supports quick name-to-file lookup (so
Tar won't fit, but ISO-9660 or even Zip probably will.)

Do I understand it correctly that for such a scheme to work, I
need to "shadow" all the common filesystem functions, either
stream-based, such as fopen (), or filehandle-based, such as
open (), to access the "image" instead (should the filename in
question begin with a specific prefix)?

(ISTR that AVFS [1] does something similar.)

[1] http://avf.sourceforge.net/

I guess that I won't be able to run a binary contained within
such an "image" on the common systems of today?

TIA.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,7 ביולי 2012 11:53:02 UTC+1, מ×ת Ivan Shmakov:

Suppose that I need to develop a "few files only" application.

My idea is that the files would be: the immutable data file, the
mutable data file, and the executable binary; though I'm not yet
sure if I'd need to keep all the working data in a single file.

Then, the immutable data file could be pretty much any kind of
an archive, as long as it supports quick name-to-file lookup (so
Tar won't fit, but ISO-9660 or even Zip probably will.)

Do I understand it correctly that for such a scheme to work, I
need to "shadow" all the common filesystem functions, either
stream-based, such as fopen (), or filehandle-based, such as
open (), to access the "image" instead (should the filename in
question begin with a specific prefix)?

C should provide this facility. Whilst object-orientation is a nuisance generally, the ability to define abstract "streams" is an exception. All that's needed is an interface, FILE *overloadedfopen( int (*getc)(void *ptr), int (*putc) (int ch, void *ptr)) that allows you to define your own streams. Then frwrite etc on the file pointer is implemented in terms of your supplied putc().
But it has to be quite a bit clumsier to support seeking and telling and ungetc().

As it is, you can't do this. But you can define your own MYFILE *, and myfopen(), myfclose(), etc. Then you write and test all your functions using stdio, and just go through them prepending mys when it comes to move to the packaged file system.

 

[Nobody]

Then, the immutable data file could be pretty much any kind of
an archive, as long as it supports quick name-to-file lookup (so
Tar won't fit, but ISO-9660 or even Zip probably will.)

Do I understand it correctly that for such a scheme to work, I
need to "shadow" all the common filesystem functions, either
stream-based, such as fopen (), or filehandle-based, such as
open (), to access the "image" instead (should the filename in
question begin with a specific prefix)?

For Linux or BSD, you can use (respectively) fopencookie or funopen to
create user-defined streams which will work with anything that uses stdio
(i.e. you can pass the resulting FILE* to library functions which know
nothing of your implementation). Unfortunately, I don't know of anything
similar for Windows.

You can't reliably implement descriptor-based I/O, as that involves the
kernel (e.g. inheritance of descriptors by child processes).

I guess that I won't be able to run a binary contained within
such an "image" on the common systems of today?

Maybe. On Unix, you can get a close approximation to execve() simply by
making the correct mmap/munmap calls, assuming that you don't need to
support setuid/setgid binaries. However, this requires that the files
within the archive are aligned to page boundaries.

 

[Jorgen Grahn]

Suppose that I need to develop a "few files only" application
(so to make it convenient to pass around for the users of the
systems lacking decent package management) based on an existing
"way too many files to install manually" one (written in C.)

Which systems don't have a standard archiver format? Tell them to
unpack a ZIP file (on Windows) or a tar.gz elsewhere, and you only
have one file to pass around, yet you can arrange your data in a
natural way, Not surprisingly, that's the way it's usually done.

Or am I missing something?

/Jorgen