Darren Reed wrote:
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.
Which is I believe covered by one or more of the following CRs:
5105713 want new security attributes on files
64174
[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 w
On Jun 11, 2006, at 03:21, can you guess? wrote:
My dim recollection is that TOPS-10 implemented its popular (but
again <100%) undelete mechanism using the same kind of 'space-
available' approach suggested here. It did, however, support
explicit 'delete - I really mean it' facilities to he
>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 histor
But it is likely that in at least some situations promiscuously retaining
*everything*
even for a limited time would be a real problem, and that in a lot more it
would
be at least sub-optimal. Creating a directory attribute inheritable by
subdirectories
and files controlling temporary undelete-
