[EMAIL PROTECTED] wrote:

Hmm, I think I'd rather see this built into programs, such as 'rm', rather than into the filesystem itself.

For example, if I'm using ZFS for my OpenSolaris development, I might want
to enable this delete-history, just in case I rm a .c file that I need.

But I don't want to keep a history of .o, .a or executable files created, either.


And rm would know this how?

The assumption you make seems to be that .a and .o files are never valuable
where they may be; I believe *BSD used some form of "don't archive this" bit to
achieve this goal; the compiler/linker would set this bit on the files they
created but it would not be automatically copied.


Which brings me to the next point which is to say that there is probably
a need for a "never shanpshot" and "always snapshot" masks for matching
files against.


I don't see how you can determine this on the basis of the file's name or
contents.  You can determine this on the basis of how you got this file;
was it produced by the compiler, assembler, ld, yacc, lex, rpcgen, javac?

Since the number of such progams seems rather small, and the default is that
you want to keep a file, perhaps that is the way forward.  Or you could
say that you know that certain sets of processes generate repeatable results,
such as "make" and its children and make would set something inheritable
in the process word which would mark all files created during that processes
as disposible.


I think the idea you've suggested here, setting an extra
bit or property in on the file as a part of the work flow
is a better idea than the one I had in mind.

Is passing a new flag through open(2) a way to achieve this,
such as O_DISPOSABLE (that is ignored by filesystems that
don't have any way to handle it), or should tools such as
make check to see if they're creating a file on ZFS and set
the extra bit appropriately with another system call?

Darren

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to