Re: [Dump-users] Listing the content of a dump file without writing any data?

[Stelian P. <st...@po...>]

Le vendredi 04 janvier 2008 à 18:26 +0000, Keith G. Robertson-Turner a
écrit :
> Verily I say unto thee, that Stelian Pop spake thusly:
> > On Fri, Jan 04, 2008 at 06:49:06AM -0800, Kenneth Porter wrote:
> 
> >> This is one of those use cases where being able to mount the dump 
> >> like an ISO9660 filesystem would be handy. ;)
> > 
> > I'm not sure the sequential nature of a dump is compatible with some
> > sort of loop mount... Especially if the dump is located on a real 
> > tape :)
> 
> That'd make an interesting side project.
> 
> What does the layout of a dump file look like, semantically?

It's composed of a map of inodes on the tape, then a sequential stream
of all the directories on the tape, then a sequential stream of all the
other type of files on the tape.

This means that if you want the directory structure you only have to
extract the directory part. But unfortunately there isn't much more
information than the inode number and the pathname here, if you want the
size, the permission bits etc you'll have to seek forward until you
encounter the real inode (meta)data.

> Wouldn't it be possible to create a virtual filesystem based on the dump
> header, which subsequently calls "restore" when actually working with
> files? 

Not a full filesystem, see above why. For a simple (names only) view,
sure, this is what restore -i do.

> These would then be temporarily extracted to /tmp ... somewhat
> like file-roller or similar?
> 
> That way, the actual data would not need to be extracted first, it would
> be a much faster operation, use less memory and disk space, and
> (assuming the inode info can be retrieved without fully restoring the
> entire dump) this would work just as well with tape as a dump file.

No, you'll have to either generate 'false' information about the inodes
or analyse the whole dump to extract the real information.

> I'm thinking along the lines of integration with gnome-vfs or similar.

> Something to think about in the long term, anyway.

Stelian.

-- 
Stelian Pop <st...@po...>