Junio C Hamano <gits...@pobox.com> wrote:
> Johannes Sixt <j...@kdbg.org> writes:
> > Am 08.07.2014 21:34, schrieb Jens Lehmann:
> >>> And Msysgit complains 
> >>> error: fchmod on c:/xxxt/trash 
> >>> directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
> >>>  failed: Function not implemented
> >> 
> >> I'm not sure what this is about, seems to happen during the "cp -R" of
> >> the repo under .git/modules into the submodule.
> >
> > No. It happens because fchmod() is not implemented in our Windows port.
> >
> > Please see my band-aid patch at
> > http://thread.gmane.org/gmane.comp.version-control.git/248154/focus=20266
> > The sub-thread ended inconclusive.
> We need to start somewhere, and a no-op fchmod() in your patch may
> be as a good place to start as anything.  At least we would then
> keep the old behaviour without introducing any new failure.

Right, this likely makes the most sense for single-user systems or
systesm without a *nix-like permission system.

> An alternative might be to use chmod() after we are done writing to
> the config.lock in order to avoid the use of fchmod() altogether,
> which I think can replace the existing two callsites of fchmod().
> That approach might be a more expedient, but may turn out to be
> undesirable in the longer term.

In that case, we would need to open with mode=0600 to avoid a window
where the file may be world-readable with any data in it.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to