forked from NuGet/NuGet.Client
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Handle potential for long file paths when creating cache files #40
Labels
Bug
Issues where something has happened which was not expected or intended
Milestone
Comments
gep13
added
the
Bug
Issues where something has happened which was not expected or intended
label
Jun 13, 2023
gep13
added a commit
to gep13/NuGet.Client
that referenced
this issue
Jun 13, 2023
During testing, it was found that there are cases where a very long query string was causing a problem when caching the file earlier in the callstack than the earlier testing. This problem is caused when a call into a BCL method throws a long file path exception, even though the Operating System has been enabled to use long path file support. Due to this, we have introduced a check to see if the file path is longer than the allowed length, and if it is, immediately create the hashed filename. This commit adds a new helper method, GetHashedCacheFileName. which is used to calculate the hashed file name, in a single location, rather than duplicating the work in multiple places. In addition, the original code which attempted to store the hash file has been left in place (just in case) and updated to use this new shared method.
10 tasks
gep13
added a commit
to gep13/NuGet.Client
that referenced
this issue
Jun 13, 2023
During testing, it was found that there are cases where a very long query string was causing a problem when caching the file earlier in the callstack than the earlier testing. This problem is caused when a call into a BCL method throws a long file path exception, even though the Operating System has been enabled to use long path file support. Due to this, we have introduced a check to see if the file path is longer than the allowed length, and if it is, immediately create the hashed filename. This commit adds a new helper method, GetHashedCacheFileName. which is used to calculate the hashed file name, in a single location, rather than duplicating the work in multiple places. In addition, the original code which attempted to store the hash file has been left in place (just in case) and updated to use this new shared method.
gep13
added a commit
to gep13/NuGet.Client
that referenced
this issue
Jun 13, 2023
During testing, it was found that there are cases where a very long query string was causing a problem when caching the file earlier in the callstack than the earlier testing. This problem is caused when a call into a BCL method throws a long file path exception, even though the Operating System has been enabled to use long path file support. Due to this, we have introduced a check to see if the file path is longer than the allowed length, and if it is, immediately create the hashed filename. This commit adds a new helper method, GetHashedCacheFileName. which is used to calculate the hashed file name, in a single location, rather than duplicating the work in multiple places.
AdmiringWorm
added a commit
that referenced
this issue
Jun 13, 2023
(#40) Handle long file paths when caching files
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checklist
What You Are Seeing?
An error is thrown when running an open-ended search command against some sources. This is due to the fact that on these sources, there is no search resource, which means a list resource is used instead. When this happens, a VERY long query URI is created, which causes an exception higher up in the call stack than was seen previously during testing.
What is Expected?
The command should return with a list of packages that meet the query that was performed.
How Did You Get This To Happen?
This can be simulated by running an open ended query against any NuGet Feed that doesn't provide a search resource. For example, you can run the following command:
System Details
Installed Packages
Output Log
Additional Context
This is a follow up issue created which relates to this one:
#36
It was originally believed that enough work had been done to prevent an exception being thrown, however, when testing with other queries, it was found that this was still a problem.
The text was updated successfully, but these errors were encountered: