Skip to content
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

Migration fails on Windows when using long paths #61

Closed
jacobilsoe opened this issue Sep 16, 2015 · 4 comments
Closed

Migration fails on Windows when using long paths #61

jacobilsoe opened this issue Sep 16, 2015 · 4 comments

Comments

@jacobilsoe
Copy link
Contributor

Migration on Windows will fail if you have too long paths. The problem is in handle_captitalization_filename_changes where an os.chdir is executed. This will fail if the path is too long:

FileNotFoundError: [WinError 206] The filename or extension is too long

Instead of doing an os.chdir maybe call git ls-files with the folder as argument. Git can be configured to work with long paths like this: git config --system core.longpaths true (this works for me at least).

@WtfJoke
Copy link
Member

WtfJoke commented Sep 16, 2015

How long was the path? Can windows itself still do stuff there? I mean can you edit the name of the folder for example through the window explorer or can you cd into it in the console (cmd)?

How did core.longpaths changed the behaviour? Afterwards everything worked well with the existing code? If yes, a fix would be easy. We could just set this property in the beginning.

EDIT: Here some information I found about the option/limitation.
Original pull: msysgit/git#122
Merge with documentation: git-for-windows/git@d09ca80
Config.txt documentation: https://github.com/msysgit/git/blob/master/Documentation/config.txt#L640

According to this documentation I hesistate now a bit more to set this option all the time. Maybe we can detect somehow if the path is too long and then set this config entry....

@jacobilsoe
Copy link
Contributor Author

Yes, we should not enable it by default. Maybe write a note about it on the wiki? Enabling it solved my problems though. If I get some time, I will have a look at handle_captitalization_filename_changes.

@WtfJoke WtfJoke added the wiki label Sep 17, 2015
@WtfJoke
Copy link
Member

WtfJoke commented Sep 17, 2015

True, a wiki entry would be helpful in that case.

@WtfJoke
Copy link
Member

WtfJoke commented Oct 20, 2015

I wrote a short wiki-entry.
You can review it and if necessary enhance/edit it.

@WtfJoke WtfJoke closed this as completed Oct 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants