Darren J Moffat <darr...@opensolaris.org> wrote:
> > You cannot get a single file out of the zfs send datastream.
>
> I don't see that as part of the definition of a backup - you obviously
> do - so we will just have to disagree on that.
If you need to set up a file server of the same size as the original one
in order to be able to access a specific file from backup data, this could be
sees as major handicap.
> >> getattrat(3C) / setattrat(3C)
> >>
> >> Even has example code in it.
> >>
> >> This is what ls(1) uses.
> >
> > It could be easily possible to add portable support integrated into the
> > framework that already supports FreeBSD and Linux attributes.
>
> Great, do you have a time frame for when you will have this added to
> star then ?
I need to write some missing 50 lines of code (formatting virgin BD-RE and
BD-RE/DL media) in cdrecordl and publish cdrtools-3.0-final before I start
working on other projects, but this will hopefully be soon.
> > - A public interface to get the property state
>
> That would come from libzfs. There are private interfaces just now that
> are very likely what you need zfs_prop_get()/zfs_prop_set(). They aren't
> documented or public though and are subject to change at any time.
mmm, as the state of the compression flag may seriously affect media
consumption, this seems to be an important part of the meta data in case of a
backup. Is there no way to define an interface that will just evolve without
becoming ncompatible?
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
