-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git ask for a dvd in dvd player. #329
Comments
Oh, and it could also be the |
I think you meant %PATH% ^^: There's no D: in it. edit: i disinstalled and reinstalled, still the same(and dvd player was empty this time). |
Call Git Bash and you will see |
$ /etc/mtab I really dont know what you mean... |
/etc/mtab is a file, not a directory or executable.
is what dscho asked for. Furthermore you will notice that the original command that has been requested by dscho will work now in Git Bash. echo $PATH | tr ':' '\n' |
$ cat /etc/mtab $ cat /etc/fstab For a description of the file format, see the Users Guidehttp://cygwin.com/cygwin-ug-net/using.html#mount-tableDO NOT REMOVE NEXT LINE. It remove cygdrive prefix from pathnone / cygdrive binary,posix=0,noacl,user 0 0 Well, git bash works perfectly fine, but not git in windows command. |
Add also the output of echo $PATH | tr ':' '\n' to be complete sure that D: is not in PATH of Git Bash. |
$ echo $PATH | tr ':' '\n' Its not in. |
Does the message box also appear when you call |
No, the message box was only appearing in windows command shell, not git bash(which works perfectly fine, but no scrolling :(). git status pops up the message only if its a git repository. commands that does not pop the message: unsure ones:(remote didnt change so fetch does nothing for now). |
Please set your environment variable |
I have the same problem. When I'm at work, everything works fine. At home, I get this popup each time I refresh Git Gui or gitk (which is often). Git Bash does not have this problem. This started after upgrading to Git for Windows 2.5.0. Git for Windows 2.5.1 is also affected. I've figured out that D: is one the memory card slots in my monitor at home, which explains why the problem depends on where I am. When I re-assign that drive to something else, say H:, then the problem disappears. So for some reason, git tries to access drive D:, but not drives E:/F:/G:/H:. I cannot figure out why git tries to access drive D:. Using process explorer, I figured out that the git-process that gets launched by Git Gui is launched the following PATH (newlines inserted for legibility).
Using this PATH, I was able to reproduce the problem in a fresh
With some trial and error, I came up with this minimal setup that reproduces the problem. (This directory is not a git repo.)
I have tried getting more info using
I'm stuck at this point. Any ideas? |
The best idea would be to rebuild Git via the SDK after removing the However, this will take some time to set up and it will also download quite a bit of data. @odegroot do you have a chance to do that? If so, I'll try my best to walk you through the process. |
@dscho Not really, no. Is there someone that already has a developer setup and is not using their D: drive? If they assign a removable drive to D: and make sure that no media is inserted, then they should be able to reproduce the problem. DVD drive, cardreader, virtual DVD drive, any kind of removable drive should trigger it. |
Using Sysinternals' Process Monitor, I see this when just running git:
Seems something is trying to open Stack as shown in Process Monitor:
|
@kgybels this is an excellent analysis, and an excellent hint: $ strings /mingw64/bin/libintl-8.dll |grep develop
D:/develop/msys64/mingw64/share/locale
D:/develop/msys64/mingw64/share/locale So it would seem that there is a hard-coded path in |
$ pacman -Qo /mingw64/bin/libintl-8.dll
/mingw64/bin/libintl-8.dll is owned by mingw-w64-x86_64-gettext 0.19.5.1-1 The package definition is here: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gettext/PKGBUILD It can be rebuilt using $ cd /usr/src/MINGW-packages
$ git pull
$ git checkout master
$ cd mingw-w64-gettext
$ makepkg-mingw -s See also our wiki: https://github.com/git-for-windows/git/wiki/Package-management#rebuild-packages |
I got makepkg-mingw command not found :( in git bash. |
@Chairn You have to use the SDK. @dscho I have followed your instructions to rebuild the mingw-w64-gettext package, however, it seems the problem is not present in my local build:
Maybe the problem is not with the package itself, but with how it was build? If I have more time, I will take a closer look at how the build works. |
Thank you for the analysis. Did you save the output of the build (I also built
Yes, it looks like that. If so, with a little bit more information we should be able to convince the MSys2 people to rebuild Maybe even by opening a Pull Request that modifies |
So it seems as if the And indeed, it works correctly, for both of us. I had the idea that maybe our MSys2 runtime that mangles POSIX paths differently might be at fault (it should not, because the POSIX-to-Windows mangling does not happen when running any MSys2 executable, such as |
Okay, I take that one back... It looks as if the |
The `libintl-8.dll` file from mingw-w64-x86_64-gettext 0.19.5.1-1 has the path `D:/develop/msys64/mingw64/share/locale` hard-coded. As a consequence, programs that link to libintl-8.dll may try to open said directory. In many setups, `D:\` actually refers to a CD/DVD drive which means that the user may see this nasty error message: There is no disk in the drive. Please insert a disk into drive D: Let's not do that, but instead hard-code the *POSIX* path into that `.dll` file, i.e. `/mingw64/share/locale`. This fixes git-for-windows/git#329 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
See https://github.com/git-for-windows/MINGW-packages/releases/tag/temporary-gettext-release for temporary packages (until upstream releases fixed ones). |
I just verified that the version 0.19.6-1 of the mingw-w64-x86_64-gettext passes the |
This adds a new builtin, `git update-microsoft-git`, that executes the platform-specific upgrade steps to get the latest version of `microsoft-git`. On Windows, this means running `git update-git-for-windows` which was updated to use the `microsoft/git` releases page, when appropriate. See git-for-windows#321 for details. On macOS, this means running a sequence of `brew` commands. These are adapted from the `UpgradeVerb` in `microsoft/scalar`, with an important simplification: we don't need to differentiate between the `scalar` and `scalar-azrepos` cask.
This adds a new builtin, `git update-microsoft-git`, that executes the platform-specific upgrade steps to get the latest version of `microsoft-git`. On Windows, this means running `git update-git-for-windows` which was updated to use the `microsoft/git` releases page, when appropriate. See git-for-windows#321 for details. On macOS, this means running a sequence of `brew` commands. These are adapted from the `UpgradeVerb` in `microsoft/scalar`, with an important simplification: we don't need to differentiate between the `scalar` and `scalar-azrepos` cask.
This adds a new builtin, `git update-microsoft-git`, that executes the platform-specific upgrade steps to get the latest version of `microsoft-git`. On Windows, this means running `git update-git-for-windows` which was updated to use the `microsoft/git` releases page, when appropriate. See git-for-windows#321 for details. On macOS, this means running a sequence of `brew` commands. These are adapted from the `UpgradeVerb` in `microsoft/scalar`, with an important simplification: we don't need to differentiate between the `scalar` and `scalar-azrepos` cask.
This adds a new builtin, `git update-microsoft-git`, that executes the platform-specific upgrade steps to get the latest version of `microsoft-git`. On Windows, this means running `git update-git-for-windows` which was updated to use the `microsoft/git` releases page, when appropriate. See git-for-windows#321 for details. On macOS, this means running a sequence of `brew` commands. These are adapted from the `UpgradeVerb` in `microsoft/scalar`, with an important simplification: we don't need to differentiate between the `scalar` and `scalar-azrepos` cask.
I installed git for windows 2.5.0.windows.1 and it is possible that i opened and remove a DVD while installing git.
And now, everytime i use git in windows command shell, i got this message for every command:
http://i18.servimg.com/u/f18/11/55/83/62/git__d10.png
It just says : "There's no disk in player. Insert a disk in player D:".
The text was updated successfully, but these errors were encountered: