"Deletion of directory" with 1.7.0.2
orip
of prompts like
Deletion of directory 'some/dir' failed. Should I try again? (y/n)?
These are non-empty directories. I answer "n" to the prompts and
everything works fine.
Has anyone else encountered this? Is there a way to disable this
prompt?
Konstantin Khomoutov
Possibly related to the workaround for Windows way of file locking
introduced lately -- see [1] for the release notes and search for "try
again" there.
If it look slike your case check that while you're doing what causes
these error message you have no tool running wihch might have its
current directory located in one of these offending directories and no
files located in them are open.
1. http://groups.google.com/group/msysgit/msg/c1679039d7774092
orip
The directories aren't empty (so I would think they won't be deleted).
This may be related to rebasing a topic branch on a parent branch - if
I create
a directory in the topic branch that doesn't exist in the parent then
git
may try to delete it on every rebase before reapplying the patches.
Is there a way to configure this, at least?
On Mar 23, 9:13 pm, Konstantin Khomoutov <khomou...@gmail.com> wrote:
Attila Tajti
This also happens when doing a checkout from a subdirectory, eg I have
an "src" subdir in some repositories,
and execute git commands from there.
Also git rebase -i seems to hang indefinitely because of this. Normal
(non-interactive) git rebase is OK,
because the prompt was shown. However interactive rebase does not show
or do anything in my case (on Windows XP SP3 32bit)
if a directory could not be deleted. Luckily git rebase -v -i gives us
the hint: just press 'n' and enter, and it works.
(I guess the problem is that the prompt is hidden in this case.)
IMO it would be nice to be able to disable it for directories
altogether. Perhaps the best solution would be
to let the user specify a separate wildcard for files and dirs, and
show the prompt on matching items only.
On Mar 23, 10:45 pm, orip <ori...@gmail.com> wrote:
> I often do have tools open there (editors/IDEs/command prompt).
> The directories aren't empty (so I would think they won't be deleted).
>
> This may be related to rebasing a topic branch on a parent branch - if
> I create
> adirectoryin the topic branch that doesn't exist in the parent then
> git
> may try to delete it on every rebase before reapplying the patches.
>
> Is there a way to configure this, at least?
>
> On Mar 23, 9:13 pm, Konstantin Khomoutov <khomou...@gmail.com> wrote:
>
> > On 23 ÜÐà, 20:01, orip <ori...@gmail.com> wrote:
>
> > > Immediately after upgrading to msysgit 1.7.0.2 I started getting tons
> > > of prompts like
>
> > >Deletionofdirectory'some/dir' failed. Should I try again? (y/n)?
>
> > > These are non-empty directories. I answer "n" to the prompts and
> > > everything works fine.
> > > Has anyone else encountered this? Is there a way to disable this
> > > prompt?
>
> > Possibly related to the workaround for Windows way of file locking
> > introduced lately -- see [1] for the release notes and search for "try
> > again" there.
> > If it look slike your case check that while you're doing what causes
> > these error message you have no tool running wihch might have its
> > currentdirectorylocated in one of these offending directories and no
Konstantin Khomoutov
> This makes using topic branches hard to use.
[...]
> IMO it would be nice to be able to disable it for directories
> altogether. Perhaps the best solution would be
> to let the user specify a separate wildcard for files and dirs, and
> show the prompt on matching items only.
Note that this issue (if it's really caused by what I guessed in my
first message in this thread) cannot be avoided "specifically" for
directories -- you can easily reproduce what I'm talking about:
C:\tmp>mkdir foo
C:\tmp>cd foo
C:\tmp\foo>notepad
C:\tmp\foo>cd ..
C:\tmp>rmdir foo
...and here it fails to delete foo because it's being "locked" by a
copy of Notepad we spawned due to the fact Notepad has this folder as
its "current directory".
That said, it seems to me that more investigation is needed by those
for whom the new change breaks things: what tools do you use, precise
workflow and how it fails etc. Otherwise it's just a handwaving which
is hard to reproduce to see whether the problem does really exist or
it's just some misuse of certain tools.
Attila Tajti
On 26 Mar 2010, at 20:05, Konstantin Khomoutov wrote:
> On 26 мар, 12:11, Attila Tajti <attila.ta...@gmail.com> wrote:
>
>> This makes using topic branches hard to use.
> [...]
>> IMO it would be nice to be able to disable it for directories
>> altogether. Perhaps the best solution would be
>> to let the user specify a separate wildcard for files and dirs, and
>> show the prompt on matching items only.
>
> Note that this issue (if it's really caused by what I guessed in my
> first message in this thread) cannot be avoided "specifically" for
> directories -- you can easily reproduce what I'm talking about:
> C:\tmp>mkdir foo
> C:\tmp>cd foo
> C:\tmp\foo>notepad
> C:\tmp\foo>cd ..
> C:\tmp>rmdir foo
> ...and here it fails to delete foo because it's being "locked" by a
> copy of Notepad we spawned due to the fact Notepad has this folder as
> its "current directory".
I understand why is this happening on Windows, and understand the purpose of this prompt, and that it is
useful for some or most people. But for me this new feature is just an annoyance, so I wondered if
there is a way to disable it altogether. Now I know I need to set GIT_ASK_YESNO=false.
Sorry for my own stupidity, but I saw the discussion about GIT_ASK_YESNO before I wrote
my first message but have not realized that this was the one I need.
I used git for almost a year now and as far as I remember I saw the "mixed branches" problem
that msysgit tries to work around with the iteractive unlink solution. But for me it was
always trivial to fix those problems with "git reset --hard && git clean -f" or the like, but
I understand that if someone uses eg. "git checkout -m" frequently this would be a serious problem.
So I was thinking about an approach that would make interactive unlink useful even for me, which
may sound selfish but I thought others might work with git the way I do: having a Command Prompt or
tools like Vim or Visual Studio open in a subdirectory inside the repository.
This means that I will see a lot of "try again" prompts because the directory cannot be unlinked,
that is known to be harmless. But I would still find those prompts for normal files useful.
So my opinion was that it would be the best to be able to disable it altogether or just
for directories.
But now I see there is this hook in place already, if I may put my two cents in, a better way
would be to delegate all the asking stuff to an external script that gets both the path and
message in question as an argument. The default script would do exactly what 6a5f4e5 did,
but people like me could modify it to always skip the prompt for directories.
Thank you for your time and best regards.
Heiko Voigt
On Sat, Mar 27, 2010 at 09:25:12PM +0100, Attila Tajti wrote:
>
> On 26 Mar 2010, at 20:05, Konstantin Khomoutov wrote:
>
> > On 26 мар, 12:11, Attila Tajti <attila.ta...@gmail.com> wrote:
> >
> >> This makes using topic branches hard to use.
> > [...]
> >> IMO it would be nice to be able to disable it for directories
> >> altogether. Perhaps the best solution would be
> >> to let the user specify a separate wildcard for files and dirs, and
> >> show the prompt on matching items only.
> >
> > Note that this issue (if it's really caused by what I guessed in my
> > first message in this thread) cannot be avoided "specifically" for
> > directories -- you can easily reproduce what I'm talking about:
> > C:\tmp>mkdir foo
> > C:\tmp>cd foo
> > C:\tmp\foo>notepad
> > C:\tmp\foo>cd ..
> > C:\tmp>rmdir foo
> > ...and here it fails to delete foo because it's being "locked" by a
> > copy of Notepad we spawned due to the fact Notepad has this folder as
> > its "current directory".
The implementation is targeted at exactly this kind of problem. In case
git can not delete a directory because something is using it. But during
the time I have been using the new version in some cases I could not find
(and kill) the process which was using the directory. So there is
probably room for improvement.
[...]
> This means that I will see a lot of "try again" prompts because the directory cannot be unlinked,
> that is known to be harmless. But I would still find those prompts for normal files useful.
> So my opinion was that it would be the best to be able to disable it altogether or just
> for directories.
I see you already found the right way of disabling the whole thing. The
current implementation is kind of a test balloon of how much we actually
need to handle.
Would a checkbox "[ ] apply this answer to all further failures" help
you in your case? Or does it depend on your workflow and you would say
that it will always ask you that question during certain steps?
cheers Heiko
Attila Tajti
This means that I will see a lot of "try again" prompts because the directory cannot be unlinked,that is known to be harmless. But I would still find those prompts for normal files useful.So my opinion was that it would be the best to be able to disable it altogether or justfor directories.
I see you already found the right way of disabling the whole thing. The
current implementation is kind of a test balloon of how much we actually
need to handle.
Would a checkbox "[ ] apply this answer to all further failures" help
you in your case? Or does it depend on your workflow and you would say
that it will always ask you that question during certain steps?
Heiko Voigt
> 3. For some projects it makes sense to have programs (be it git
> itself, an IDE or just a cmd.exe) running within a project
> subdirectory, in which case this message will always appear. In this
> case the current algorithm is not helpful: even if one keeps the
> prompt to be safe from the potential error we are trying to address,
> answering no without thinking can become a habit. So one might just
> type no accidentally in case of an actual error defeating the purpose
> of the prompt.
If we are only talking about this use case it might make sense to just remove
the retry question for directories. You could test this by reverting commit
03a5d4 which implemented it.
AFAIK, checkout does not fail in case a directory is in use and other
operations can proceed fine. My original target was git clean which
failed for directories in use sometimes. A failed clean does not mean
that you are ending up in such a confusing state as a failed checkout so
stopping for a directory might not be worth the effort.
> This is why I suggested to have a filter based on the path: I can be
> just as safe as I want. In this case I had the following choices:
>
> a. Have the prompt disabled like I do it now, but probably it is not a
> good idea.
Yes that should not be the default because it makes loosing changes more
likely in case of a failed checkout and locally modified files.
> b. I could disable the functionality for all directories which seems
> to be relatively safe as far as I can tell
As described above that could be the way to go.
> c. I know that I have tools always running in one specific
> subdirectory of my projects (eg. src in my case), with a filter tool I
> could also omit only this single specific directory.
This sounds like a complicated solution to a simple problem.
> d. Have the prompt enabled all the time.
>
> I was trying to think out other, simpler ways to do it that would
> probably fit everyone but I could think of none that worked.
We should first try to take the simplest approach (removing the check
for directories) which might work for everyone and see whether we hit
any obstacles.
cheers Heiko