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

Handle potential for long file paths when creating cache files #40

Closed
4 tasks done
gep13 opened this issue Jun 13, 2023 · 1 comment · Fixed by #41
Closed
4 tasks done

Handle potential for long file paths when creating cache files #40

gep13 opened this issue Jun 13, 2023 · 1 comment · Fixed by #41
Assignees
Labels
Bug Issues where something has happened which was not expected or intended
Milestone

Comments

@gep13
Copy link
Member

gep13 commented Jun 13, 2023

Checklist

  • I have verified this is the correct repository for opening this issue.
  • I have verified no other issues exist related to my problem.
  • I have verified this is not an issue for a specific package.
  • I have verified this issue is not security related.

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:

choco search --source chocolatey.licensed

System Details

  • Operating System: Win 10
  • Windows PowerShell version: 5.1
  • Chocolatey CLI Version: 2.0.0 development build
  • Chocolatey Licensed Extension version: N/A
  • Chocolatey License type: N/A
  • Terminal/Emulator: PowerShell

Installed Packages

None

Output Log

N/A

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.

@gep13 gep13 added the Bug Issues where something has happened which was not expected or intended label Jun 13, 2023
@gep13 gep13 added this to the 3.3.0 milestone Jun 13, 2023
@gep13 gep13 self-assigned this 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.
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
gep13 added a commit that referenced this issue Jun 13, 2023
* release/3.3.0:
  (maint) Add missing . at end of template
  (#40) Handle long file paths when caching files
  (maint) End Chocolatey Specific Modification
  (#38) Allow getting the system proxy
  (build) Starting building 3.3.0 on develop branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Issues where something has happened which was not expected or intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants