Re: [Linux-NTFS-Dev] Implementing ntfsimage

[Ian J. <ia...@da...>]

Anton Altaparmakov writes ("Re: [Linux-NTFS-Dev] Implementing ntfsimage"):
> I agree that a simple image format is a good idea but I also think that
> being able to create a simple sparse file for debugging purposes
> especially a metadata only file is extremely valuable, too.

This can be done, of course, just by piping the output of the imager
into the restorer.  The few resulting extra memory copies will
probably pale into insigificance next to the overhead of disk reads
and writes.  Although, I'll try it and see.

>  If we can combine the two utilities that would probably be the best
> thing. My suggestion would be to create one utility rather than two
> different ones and that utility for example (just picking at random,
> feel free to use different) takes a first parameter "b" for create
> image/backup, "r" for restore image/backup and then a second
> optional parameter say "s" for working with a sparse file as the
> source ("r"/restore case) or destination ("b"/backup case). Much
> like the tar utility works in a way...

I think this is a bad idea because the image format isn't
ntfs-specific, so the restorer is really only in the ntfsprogs as a
convenient place to put it.  The imager and the restorer hardly share
any code at all (pretty much only the format magic number, so far).

> Yes, of course. But ideally I would like to see the two functionalities in
> one rather than having two separate imaging programs, one for sparse
> files and one for custom image format...

Certainly if a program is needed to make sparse files (rather than
just feeding the custom image stream into the restorer), it should be
the same program as the imager that generates a stream.

> >  - restoreimage should be able to create the image as a sparse file. I
> >    don't think this would be a big issue.
> 
> I think this is the wrong level. I really don't want to have to create an
> image to be able to create a sparse file from that, that would take twice
> the space on disk and twice the time.

You don't have to store the image stream anywhere (indeed, you'd
probably prefer not to for the reasons you say).

>  Not worth it IMHO. Much better to have the imaging program do it
> immediately on image creation.

Is the additional complexity in the imager worth it to avoid the need
to run two commands (or have a shell alias) ?

>  It would also be really nice if on restore the imaging program can
> take the sparse file and use that to restore the data to the
> partition.

Copying a sparse file to a partition isn't a restore, it's an
image-and-restore.  So in my model you use the imager and restorer,
just as before.

Ian.