4b1b9d7a83Freeze first sets the file perms, and then runs freezecontent-command. Thaw runs thawcontent-command before restoring file permissions. This is in case the freeze command prevents changing file perms, as eg setting a file immutable does. Also, changing file perms tends to mess up previously set ACLs. git-annex init's probe for crippled filesystem uses them, so if file perms don't work, but freezecontent-command manages to prevent write to a file, it won't treat the filesystem as crippled. When the the filesystem has been probed as crippled, the hooks are not used, because there seems to be no point then; git-annex won't be relying on locking annex objects down. Also, this avoids them being run when the file perms have not been changed, in case they somehow rely on git-annex's setting of the file perms in order to work. Sponsored-by: Dartmouth College's Datalad project
59 lines
2.2 KiB
Markdown
59 lines
2.2 KiB
Markdown
Add git hooks that are used to [[internals/lockdown]] annexed objects.
|
|
--[[Joey]]
|
|
|
|
Use cases include:
|
|
|
|
* Setting immutable bit on systems where git-annex is given the ability to
|
|
do so, to fully guard against accidental deletion in all circumstances.
|
|
|
|
* For systems that ignore the write bit, but have some other way to prevent
|
|
write to a file (eg, ACLs or something).
|
|
|
|
Note that in such a case, `git-annex init`'s probe of the write bit
|
|
handling fails; as long as the hook is configured globally, it should
|
|
run the hook instead, and if it works, can avoid direct mode.
|
|
|
|
Design:
|
|
|
|
Configs: annex.freezecontent-command, annex.thawcontent-command
|
|
In these, "%path" is replaced with the file/directory to act on.
|
|
|
|
Locking down a directory only needs to do the equivilant of removing its
|
|
write bit, does not need to lockdown the files within it.
|
|
|
|
It would be up to the command to decide how to handle the
|
|
core.sharedRepository configuration.
|
|
|
|
These could be set in the global gitconfig file. The IncludeIf directive
|
|
can be used to make them be used only for repositories located within a given
|
|
mount point.
|
|
|
|
git-annex test disables use of global gitconfig settings. There would need
|
|
to be a way to let it use these.
|
|
|
|
Perfomance:
|
|
|
|
Hook would be called twice per store/drop of an annexed object,
|
|
once for the file and once for the parent directory.
|
|
|
|
On windows, called four times per lock of an annexed object, to first thaw
|
|
it and then freeze it. This could be reduced to 2, I think.
|
|
On posix, the file is locked without being thawed,
|
|
as only read access is needed.
|
|
|
|
Probably running a shell script is not too much overhead in many cases,
|
|
if it was too slow, there could be a variant that is run once and
|
|
fed the names of files to operate on via stdin.
|
|
|
|
> These hooks may be too specific to this purpose, while a more generalized
|
|
> hook could also support things like [[storing_xattrs|support_for_storing_xattrs]]
|
|
> --[[Joey]]
|
|
|
|
[[!tag projects/datalad]]
|
|
|
|
> [[done]].. `git-annex init` does run annex.freezecontent-command and if it
|
|
> prevents writing to a file, it will avoid setting
|
|
> annex.crippledfilesystem.
|
|
>
|
|
> I didn't make `git-annex test` use the global git config of the hooks
|
|
> though, not sure if that really makes sense or is needed.
|