ngclient: downloading targets fails if targetpath includes subdirectories
See original GitHub issuengclient has so far copied the legacy client decision of downloading files to the same directory structure as the repository uses. It has however removed the code that creates the directory structure.
So downloading any targets with paths like "path/to/file"
will fail because the local directories do not exist.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
PowerTip: List all subfolders under a target path with PowerShell
I used to use tree.com to get a list of folders on a computer. Is there something close to that in PowerShell? Maybe...
Read more >C# Download all files and subdirectories through FTP
I.e. you can try to download the "name". If that succeeds, it's a file, if that fails, it's a directory. You may be...
Read more >Failed to build the list of regular subfolders - YouTube
If you configured a new GPO which redirects User folders to a new network share, or you click on Reset default location under...
Read more >Copy and Create Destination Directory if it Does Not Exist
The cp command refuses to do that because the target directory doesn't exist. This happens pretty often when we copy files: First, we...
Read more >Level up with these advanced PowerShell commands to copy ...
If the file in the target directory is set to read-only, you'll get an error. Copy-Item -Path C:\test\p1.txt -Destination C:\test2\ Copy-Item : ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That’s fine, I’m sure you needed to do something to test – and we are annoyingly touching the same bits of code. We’ll see how bad the merging/rebasing gets…
I don’t want to create local directories based on a URL – a specific TUF implementation might know that is a reasonable thing to do but I don’t think the library can know that. I’m suggesting we use the whole target path (url encoded) as a filename, and then also offer a way for the client application to decide the filepath themselves (so if the client knows using target path as path is safe, it can create the directories).
@jku I am sorry I created a commit before reading this issue and noticing you are assigned to it. I created one commit possibly solving that issue: https://github.com/theupdateframework/python-tuf/pull/1591/commits/6f108c9a1f7822b863b0118d8159e108b850bca8, but the question remains do we want to further support targetpaths as local paths.
What other do you mean besides this one if we consider targetpaths as local paths?