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
