chattr

[bscott at ntisys.com]

On Tue, 28 Jan 2003, at 4:12pm, Marc at softwarehackery.com wrote:
>> ..there is an inherent paradox in synchronizing an immutable file ...
> 
> So, how would one create a backup of a system that has attributes set ...

  For other attributes, it is a simple matter of programming[1].  The
dump2fs(8) program can already handle them.  Perhaps tar(1) or cpio(1)  
could be extended yet again to handle non-traditional attributes.  Perhaps
it is time for a more flexible archive program to be designed (actually, it
has been that time for a while).

  The problem I describe is only with the immutable bit.  Consider the
fairly common scenario of a full backup, followed by an incremental backup.  
You wish to restore said backups.  What is the right thing to do if an
immutable file is contained within both the full and the incremental
savesets?  It should be restored from the incremental saveset, because that
is the most recent version; at the same time, the system should not allow
the immutable file from the original saveset to be modified.  That is, after
all, the point of the immutable bit; programatically overriding that
behavior defeats the purpose.

> Truely sad ...

  Truly sad?  No.  As I said, it is an inherent paradox.  Inherent, meaning
"inseparably attached or connected", and paradox, meaning "an assertion or
sentiment seemingly contradictory"[2].  An immutable file, by definition,
cannot be changed.  How, then, do you restore it?

  One obvious solution (as mentioned previously) would be to have the
archive tool remove the immutable bit, restore the file, and then replace
the bit.  But (as also mentioned previously) that defeats the purpose of the
immutable bit.

  An idea that appeals to me is to never backup or restore the immutable
bit.  When setting the bit in the first place, instead of doing so directly,
create a list of files to be set immutable, and feed that to "chattr +i"  
automatically.  That list can then be archived with the rest of the
filesystem, and applied again at the end of a restore.  Of course, this does
not solve the problem; it simply bypasses it.

  As with any paradox, there is no right answer.


Footnotes
---------
[1] http://www.catb.org/~esr/jargon/html/entry/SMOP.html
[2] All definitions from Webster's 1913 _Revised Unabridged Dictionary_.

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |