git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: dwheeler@dwheeler.com
Cc: torvalds@osdl.org, mwelinder@gmail.com, mj@ucw.cz, git@vger.kernel.org
Subject: Re: Storing permissions
Date: Sun, 17 Apr 2005 01:13:01 -0700	[thread overview]
Message-ID: <20050417011301.0b341d5d.pj@sgi.com> (raw)
In-Reply-To: <42620092.9040402@dwheeler.com>

David wrote:
> There's a minor reason to write out ALL the perm bit data, but

There's always the 'configurable option' approach.

Someone, I doubt Linus will have any interest in it, could volunteer to
make the masks of st_mode, used when storing and recovering file
permissions, be configurable by some environment variable settings,
which default to whatever Linus provided.

But, in general, if you want a generalized backup system, git is not it.

Git skips all files whose name begins with the dot '.' character, and
anything that is not a regular file or directory.  Git makes no
concessions to working adequately on file systems lacking normal inode
numbers (such as smb, fat, vfat).  Git obscures the archive format a
modest amount, for pure speed and to encourage use only via appropriate
wrappers.  Git is tuned for blazing speed at the operations that Linus
needs, not for trivial recovery, using the most basic tools, under harsh
circumstances.

The basic idea of using such an 'object database' (though I dislike that
term -- too high falutin vague) of files stored by their hash is a
good one.  But a different core implementation is needed for backups.

I have one that I use for my own backups, but it is written in Python,
and uses MD5, one or the other of which likely disqualifies it from
further consideration by half the readers of this list.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

  reply	other threads:[~2005-04-17  8:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-16 23:00 Storing permissions Martin Mares
2005-04-16 23:19 ` Paul Jackson
2005-04-16 23:42   ` Junio C Hamano
2005-04-17  0:03     ` Paul Jackson
2005-04-17  5:00       ` David A. Wheeler
2005-04-17  1:01 ` Morten Welinder
2005-04-17  1:30   ` Paul Jackson
2005-04-17  4:48     ` Linus Torvalds
2005-04-17  5:32       ` Paul Jackson
2005-04-17  5:37       ` Linus Torvalds
2005-04-17  6:22       ` David A. Wheeler
2005-04-17  8:13         ` Paul Jackson [this message]
2005-04-17 14:51         ` Daniel Barkalow
2005-04-17 16:10         ` Linus Torvalds
2005-04-17 16:21           ` David A. Wheeler
2005-04-17 22:15             ` Symlinks [was Re: Storing permissions] Morten Welinder
2005-12-07 14:56             ` dotfile support Zack Brown
2005-12-07 15:28               ` Andreas Ericsson
2005-12-07 16:11                 ` Zack Brown
2005-12-07 21:51                   ` Petr Baudis
2005-12-07 15:43               ` Johannes Schindelin
2005-12-07 17:43               ` Junio C Hamano
2005-12-07 18:19                 ` Zack Brown
2005-12-07 19:05                   ` Junio C Hamano
2005-12-08  0:47               ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050417011301.0b341d5d.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=dwheeler@dwheeler.com \
    --cc=git@vger.kernel.org \
    --cc=mj@ucw.cz \
    --cc=mwelinder@gmail.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).