Cut the Clutter: Test Ignore Files Feature - sign up to become a beta tester here!
Forum Discussion
Solved
File/Folder paths arent set
Hello,
when I try to call /files/get_metadata of any file or folder, the returned entry doesn't contain path_lower or path_display. I am assuming that means those values aren't set, but I'm not sure how that can even happen.
This is an issue because it means I can only access files via the File ID, but when you look up files/list_folder/continue for changes, the entry of a deleted file doesn't contain the file ID but it should normally contain the path. However since the path isn't set, all I am left with is the deleted tag and the file name, which isn't enough to do anything
If the path values aren't set, that means that "the file or folder is not mounted". There are a few ways that can happen:
- if you're looking at the contents of a shared folder that is itself not mounted
- if you're making an API call without an explicit "root", so the contents don't have anywhere to be "mounted" to
For example, the second one can occur if you're using a Dropbox Business API app with the "team member file acces" permission, and are supplying the "Dropbox-API-Select-Admin" header but aren't supplying the "Dropbox-API-Path-Root" header. With that admin header, you're accessing any team content, but without the root header, it isn't relative to anything. If that's the case, you should supply the root header. You can find information on how that works in the Namespace Guide.
The Content Access Guide may also be helpful reference.
Otherwise, if you share the code, I'll be happy to take a look and advise specifically.
2 Replies
- Greg-DB
Dropbox Community Moderator
If the path values aren't set, that means that "the file or folder is not mounted". There are a few ways that can happen:
- if you're looking at the contents of a shared folder that is itself not mounted
- if you're making an API call without an explicit "root", so the contents don't have anywhere to be "mounted" to
For example, the second one can occur if you're using a Dropbox Business API app with the "team member file acces" permission, and are supplying the "Dropbox-API-Select-Admin" header but aren't supplying the "Dropbox-API-Path-Root" header. With that admin header, you're accessing any team content, but without the root header, it isn't relative to anything. If that's the case, you should supply the root header. You can find information on how that works in the Namespace Guide.
The Content Access Guide may also be helpful reference.
Otherwise, if you share the code, I'll be happy to take a look and advise specifically.
Supplying the Dropbox-API-Path-Root header worked, thanks a lot!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
