Re: Consecutive git gc fails on Windows network share
- From
Erik Faye-Lund <kusmabite@gmail.com>
- Date
- Jan 21, 2014, 17:03 UTC
- Message-ID
- <CABPQNSZ5F5osOJzBbA7Q1Rbr2fcoJ7E_ZQwbQeVJwAd_3s1vvg@mail.gmail.com>
- In-Reply-To
- <alpine.DEB.1.00.1401211755330.14982@s15462909.onlinehome-server.info>
On Tue, Jan 21, 2014 at 5:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 35 quoted lines
> Hi kusma, > > On Tue, 21 Jan 2014, Erik Faye-Lund wrote: > >> On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin >> <Johannes.Schindelin@gmx.de> wrote: >> > >> > On Mon, 20 Jan 2014, Torsten Bögershausen wrote: >> > >> >> b) add "+++" at the places where you added the stat() and chmod(), >> >> c) and to send the question "is this a good implementation ?" to upstream git. >> >> >> >> I think your implementation makes sense. >> > >> > As I said in my other reply, I think that the problem would be >> > addressed more generally in compat/mingw.c. It is to be doubted highly >> > that upstream wants to handle cases such as "rename() cannot overwrite >> > read-only files on Windows" everywhere they call rename() because the >> > platforms upstream cares about do not have that problem. >> >> I'm not so sure. A quick test shows me that this is not the case for >> NTFS. Since this is over a network-share, the problem is probably >> server-side, and can affect other systems as well. >> >> So a work-around might be appropriate for all systems, no? > > I do not think that the problem occurs if you run the same commands on > Linux, on a mounted Samba share. So I guess that upstream Git can enjoy > their luxury of not having to care. > > In any case, if we would need this also for Linux, doing it for only one > user of rename() would probably not be good enough, either... so something > similar to mingw_rename() would be needed (interfering with mingw_rename > itself, of course). >
Indeed. I was thinking of something along the lines of adding a xrename in wrapper.c.
But you're probably right that this doesn't happen under Samba; surely Samba would have added a work-around for such a filesystem by now. So yeah, you've convinced me. mingw_rename is probably the place to do that.
The work-around would probably look something like this:
diff --git a/compat/mingw.c b/compat/mingw.c index a37bbf3..580b820 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1697,6 +1697,14 @@ int mingw_rename(const char *pold, const char *pnew) */ if (!_wrename(wpold, wpnew)) return 0; + + if (errno == EPERM) { + /* read-only files cannot be moved over on network shares */ + _wchmod(wpnew, 0666); + if (!_wrename(wpold, wpnew)) + return 0; + } + if (errno != EEXIST) return -1; repeat:
-- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "msysGit" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.