Child Item

GetMetadataError path/not_found/.. only in certain circumstances for files that are definitely there

Hi,
I'm writing a multiplatform .NET app which I'm testing on both Win10 and Android. Let's call this App1. I'm using GetMetaDataAsync in order to get the last modified time on a file. App1 working as expected on Windows (i.e. I get the last modified time returned to me).

Now, I run App1 on Android and it crashes. Here is the exception...

********************************** UNHANDLED EXCEPTION! Details: Dropbox.Api.ApiException`1[Dropbox.Api.Files.GetMetadataError]: path/not_found/..
at Dropbox.Api.DropboxRequestHandler.Dropbox.Api.Stone.ITransport.SendRpcRequestAsync[TRequest,TResponse,TError](TRequest request, String host, String route, String auth, IEncoder`1 requestEncoder, IDecoder`1 responseDecoder, IDecoder`1 errorDecoder)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(); Request Id: d18ae2e68ed2448681e15d0771b21e52

Given the EXACT same code (and exact same Dropbox files) it must be some kind of environmental issue. I clearly can't have the wrong path myself since the code works on Win10. Now, because building/deploying for Android is painfully slow (5 minutes!), and because App1 has many pages in it, I decide to quickly write App2 which is stripped back to JUST the page which is having the issue (the page is written as a library, so easy to quickly port a different front-end to it) - the intention here was to just try and speed up the debugging iteration cycle (hopefully get it to build/deploy quicker than 5 minutes on Android!).
The interesting thing here is that App2 crashes on Windows as well! In a way that's good as I've now reproduced the problem, and build/deploy only takes me 10 seconds (literally 10 seconds!). Unfortunately I still can't find what is causing the error. Anything you can suggest here? I've run out of ideas for things to try (e.g. tried to slow up execution a bit, but that didn't make any difference).

Summary:

App1 UWP - works

App1 Droid - crashes

App2 UWP - crashes

thanks,

Donald.

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

A 'path/not_found' error like that indicates that the call failed because there was nothing found at the specified 'path' value. There are a few things that will affect this:

Which account is being accessed: each API call is made using an access token, and that access token is specific to a particular account. Make sure you know which access token, and accordingly which account, you're using. You may be trying to access a path that exists in one account, but not another. You can check the connected account using GetCurrentAccountAsync.
The access type of the app: Apps with the "full Dropbox" access type can access anything in the account, but apps with the "app folder" access type can only access the contents of the special app folder created for them. For an app with an app folder, the supplied path value will automatically be interpreted relative to the app folder (at "/Apps/<app folder name>", by default for accounts with the English locale). Further, each account gets its own distinct app folder, even for the same app.
The root of the API call: When using a full Dropbox app, API calls default to the member folder, but if you're trying to access the "team space", you'll need to configure that specially, as covered in the Team Files Guide.

All comments

Greg-DB

A 'path/not_found' error like that indicates that the call failed because there was nothing found at the specified 'path' value. There are a few things that will affect this:

Which account is being accessed: each API call is made using an access token, and that access token is specific to a particular account. Make sure you know which access token, and accordingly which account, you're using. You may be trying to access a path that exists in one account, but not another. You can check the connected account using GetCurrentAccountAsync.
The access type of the app: Apps with the "full Dropbox" access type can access anything in the account, but apps with the "app folder" access type can only access the contents of the special app folder created for them. For an app with an app folder, the supplied path value will automatically be interpreted relative to the app folder (at "/Apps/<app folder name>", by default for accounts with the English locale). Further, each account gets its own distinct app folder, even for the same app.
The root of the API call: When using a full Dropbox app, API calls default to the member folder, but if you're trying to access the "team space", you'll need to configure that specially, as covered in the Team Files Guide.

donaldp

Hi Greg, 🙂

Thanks for your reply. I read through it and thought "nope not that, nope not that, nope not that. Hmmm, now what??". Note that this is a re-write of something I wrote before (to improve performance and enhance it). I then realised "this worked before, what have I changed?". Here was the thought process as it unfolded...

"I had the path hard-coded before, and it is now. No, wait, no it's not - I now have part of it in settings! (this is something I've added in the new version) But the settings are the same on every device. Oh no, now wait there just a minute. Settings are stored on each device - there COULD be something wrong there!". Sure enough, I found I'd missed part of the path on my phone, and thus why it was crashing on my phone and not my PC. Doh! So I was right that it was something environmental.

So thanks for your reply - it triggered a thought process that did eventually lead me to the culprit. I was wondering - can we maybe get that error message updated to include the actual path that is being looked for? If I had that I might've realised sooner where the error was.

In the meantime that's given me some ideas, like sharing settings across devices, and adding validation to what the user has typed in, because, you know, sometimes they might type in something that's actually invalid. 😉

Thanks again for your help,

Donald.

Greg-DB

Thanks for following up. I'm glad to hear you got this sorted out. I'll pass this along as feedback to see if we can improve the error returned in cases like this to include the path value itself.