Subject: Re: [msysGit] git rebase -i, mv: cannot move -
msg#00007

Previous Message by Date:

Re: [msysGit] git rebase -i, mv: cannot move

On Sun, Jan 3, 2010 at 11:02 PM, Pat Thoyts <patthoyts@xxxxxxxxxxxxxx> wrote: > > Do you have a virus checker running? They commonly look at newly > written files and while examining the file may hold it locked > preventing it from being moved. > > Pat Thoyts > Yes, I've recently installed Microsoft Security Essentials, and I've got the "Real-time protection"-option turned on. This might very well be the reason for this glitch, thanks. Is there anything we can do to avoid problems when running with antivirus on? I remember something about some patches to retry a couple of times when unlink failed or something like that... Perhaps patching 'mv' with something along those lines? -- Erik "kusma" Faye-Lund

Next Message by Date:

[msysGit] Re: Issue 389 in msysgit: git clone(and maybe other commands) does not prevent windows from hibernation.

Comment #2 on issue 389 by panychy: git clone(and maybe other commands) does not prevent windows from hibernation. http://code.google.com/p/msysgit/issues/detail?id=389 "to prevent the user from hibernating the system" Not user initiated hibernation. System automatically hibernates on idle. Any Program responsible to prevent this if it need to work. "....causing data-loss?" Hibernate process already causing data-loss (and traffic waste). Let see: I tried to clone git://git.gnome.org/gimp So while it works I decided to have some fun - played "Spider Solitaire" for 2 hours(slow connection). Then I decided to make some tea. At that moment clone process was at 92%. When I came back I saw my PC was hibernated. As a consequence: Time-loss - two hours. Data-loss - 159,5 MiB. "What if a big clone prevents a laptop with low battery and unsaved work from hibernating before losing power..." That is the users problem: 1. User knows that cloning big repository is long-term operation on low-speed connection. 2. User knows that cloning process cannot be paused and continued latter. So user MUST provide power-on state as much time as cloning process require. Else there are no reasons to start it. This is vital requirement - PC/laptop/other device MUST be turned on if somebody wants the Program to work. And Program in turn MUST notify user/automated power-save system that it does critical work and should not be interrupted. "something like resetting the idle timer (through SetThreadExecutionState) would be much more appropriate" I have not anything against this solution(and don`t know any other one yet). :) "What if a big clone prevents a laptop with low battery and unsaved work from hibernating before losing power, causing data-loss?" Make it as command line option, and all the people will be happy. :) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

Previous Message by Thread:

Re: [msysGit] git rebase -i, mv: cannot move

On Sun, Jan 3, 2010 at 11:02 PM, Pat Thoyts <patthoyts@xxxxxxxxxxxxxx> wrote: > > Do you have a virus checker running? They commonly look at newly > written files and while examining the file may hold it locked > preventing it from being moved. > > Pat Thoyts > Yes, I've recently installed Microsoft Security Essentials, and I've got the "Real-time protection"-option turned on. This might very well be the reason for this glitch, thanks. Is there anything we can do to avoid problems when running with antivirus on? I remember something about some patches to retry a couple of times when unlink failed or something like that... Perhaps patching 'mv' with something along those lines? -- Erik "kusma" Faye-Lund

Next Message by Thread:

[msysGit] Re: Issue 80 in msysgit: git-clone fails when repo contains UTF-8 filepath

Comment #48 on issue 80 by KJackie: git-clone fails when repo contains UTF-8 filepath http://code.google.com/p/msysgit/issues/detail?id=80 I think if someone really need to work with Unicode file names, he should use cygwin 1.7 instead. cygwin 1.7 support UTF-8 locale like *nix does. I don't think we should hack mingw-runtime to do the charset conversion like cygwin. Since ... 1. There are too many works to do. 2. It might reduce the performance. 3. We are creating another cygwin! noooo ... Another approach is rewrite Git by using native Windows API, and do the charset conversion in Git itself. I think this is the ideal solution, but who will do this ... -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings