Long file path problem
Closed this issue · 8 comments
This issue is for fixing long standing long file path problem.
Problem:
When history file path is longer than 259 characters, backup file is not created at all.
Quick fix:
Compile addon with framework version target at least 4.6.2 and Just use \\?\ path prefix to prepare long path for system.
https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/
PS. Good candidate for path prefix is NormalizePath() method:
Thanks for the report. I'll take a look at it again when I have some free time.
The ideal solution is to fix #4 so we don't depend on flat files anymore, but that will take a while.
I agree, it would be the best, but it needs big rewrite. Quick fix could be done "in the meantime" :-).
PS. I've tried to check fix myself, but project did not compile, need dependencies. I'll create new issue for this.
I just checked and it seems we already target 4.6.2. According to the Microsoft post, it should work without any changes.
I can't even create long path items in a solution because VS won't let me. I can use long paths normally on my machine but it seems VS 2017 doesn't like them.
How did you test long paths with VS?
This issue is not with long paths within VS projects (which is also a problem, but not LocalHistory of course), but when LocalHistory backup (on save) tries to prepare path which is almost doubled in length. Thus if i have file path: c:\d1\d2\solution\project\d3\d.ext which is longer than ~130 characters, then backup prepare path c:\d1\d2\solution\.LocalHistory\c\d1\d2\solution\project\d3\$date$d.ext, which is mostly longer than limit 259 characters.
Ah, I see. Thanks for the details.
I assumed that by targeting 4.6.2 it would work, but it seems it doesn't.
I'll test it more locally to understand it better.
As i understand, targeting at minimum 4.6.2 would work only if using path prefix. Before 4.6.2 path prefix is not available at all. Of course i could be mistaken, english is not my native.
Alright, I think I got some progress.
I used AlphaFS to handle the operations.
Also added some extra checks for labels to avoid breaking VS and some extra logic to open the diff tools. In particular, the internal diff tool VS has doesn't support long paths (like VS), so we create a temporary copy of the versioned file and operate on that.
The temporary copies are cleaned up when the solution is closed and when any solution is opened (so we can cleanup things if the previous exit was unclean).
I created a new branch for this, since it received minimal testing. After we test it a bit more, I'll push to main.
I'll try to work on VS 2019 support before attempting the DB stuff from #4, so it might take a while for us to have a proper working solution (instead of the current workarounds).
I'm attaching the build here if you or anyone else wants to test it.
It works great, thanks a lot!