<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic files/get_metadata has incorrect case for path_display in Dropbox API Support &amp; Feedback</title>
    <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186436#M7908</link>
    <description>&lt;P&gt;If I fetch the metadata for a folder and check the path_display, I get the mixed case path as desired.&lt;/P&gt;
&lt;P&gt;But if I fetch the metadata for a file within that folder, the entire path is lower case. path_display and path_lower are identical.&amp;nbsp;path_display does NOT match what is displayed on the Dropbox website.&lt;/P&gt;
&lt;P&gt;I noticed the behavior in Java but confirmed it in API explorer. You can see the behavior via &lt;A href="https://dropbox.github.io/dropbox-api-v2-explorer/#files_get_metadata" rel="nofollow noreferrer" target="_blank"&gt;https://dropbox.github.io/dropbox-api-v2-explorer/#files_get_metadata&lt;/A&gt;.&lt;/P&gt;
&lt;P&gt;This seems like a flat-out bug. Can anyone else confirm? What is the process for bug reporting at Dropbox?&lt;/P&gt;</description>
    <pubDate>Wed, 29 May 2019 09:30:28 GMT</pubDate>
    <dc:creator>Todd H.4</dc:creator>
    <dc:date>2019-05-29T09:30:28Z</dc:date>
    <item>
      <title>files/get_metadata has incorrect case for path_display</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186436#M7908</link>
      <description>&lt;P&gt;If I fetch the metadata for a folder and check the path_display, I get the mixed case path as desired.&lt;/P&gt;
&lt;P&gt;But if I fetch the metadata for a file within that folder, the entire path is lower case. path_display and path_lower are identical.&amp;nbsp;path_display does NOT match what is displayed on the Dropbox website.&lt;/P&gt;
&lt;P&gt;I noticed the behavior in Java but confirmed it in API explorer. You can see the behavior via &lt;A href="https://dropbox.github.io/dropbox-api-v2-explorer/#files_get_metadata" rel="nofollow noreferrer" target="_blank"&gt;https://dropbox.github.io/dropbox-api-v2-explorer/#files_get_metadata&lt;/A&gt;.&lt;/P&gt;
&lt;P&gt;This seems like a flat-out bug. Can anyone else confirm? What is the process for bug reporting at Dropbox?&lt;/P&gt;</description>
      <pubDate>Wed, 29 May 2019 09:30:28 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186436#M7908</guid>
      <dc:creator>Todd H.4</dc:creator>
      <dc:date>2019-05-29T09:30:28Z</dc:date>
    </item>
    <item>
      <title>Re: files/get_metadata has incorrect case for path_display</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186437#M7909</link>
      <description>&lt;P&gt;Hi Todd, this is a good place to report bugs like this.&lt;/P&gt;
&lt;P&gt;Are you seeing this only for deleted metadata, or for all metadata? There's a known issue for this for deleted metadata, but if you're also seeing this for non-deleted metadata, please share a sample so we can look into it.&amp;nbsp;Thanks in advance!&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 30 Aug 2016 05:44:04 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186437#M7909</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2016-08-30T05:44:04Z</dc:date>
    </item>
    <item>
      <title>Re: files/get_metadata has incorrect case for path_display</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186438#M7910</link>
      <description>&lt;P&gt;Having tried to reproduce this with non-proprietary files I see the problem is more subtle. It has to do with folders&amp;nbsp;being removed and added back with a different case.&lt;/P&gt;
&lt;P&gt;Steps to reproduce:&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;Create a folder called Test&lt;/LI&gt;
&lt;LI&gt;Add a folder called lowercase.&lt;/LI&gt;
&lt;LI&gt;Delete the folder named lowercase&lt;/LI&gt;
&lt;LI&gt;Add a folder named LowerCase&lt;/LI&gt;
&lt;LI&gt;Add a file named Error.png&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;We have:&lt;/P&gt;
&lt;P&gt;&lt;IMG src="https://www.dropboxforum.com/hc/user_images/zJUzshHoB9c1Ao9Jwgey4w.png" /&gt;&lt;/P&gt;
&lt;P&gt;Now we let's look&amp;nbsp;at the&amp;nbsp;API view. It correctly shows the path_display of “/Test/LowerCase”&lt;/P&gt;
&lt;P&gt;&lt;IMG src="https://www.dropboxforum.com/hc/user_images/1a5fP0PpI7s-Lz1slGO8gg.png" /&gt;&lt;/P&gt;
&lt;P&gt;But when I get the metadata for the file, it shows the incorrect case for the folder which was deleted and added with a different case. It shows “/Test/lowercase/Error.png” but I would expect “/Test/LowerCase/Error.png”&lt;/P&gt;
&lt;P&gt;&lt;IMG src="https://www.dropboxforum.com/hc/user_images/R56g4Cr4gf2DexOe4s50Qg.png" /&gt;&lt;/P&gt;
&lt;P&gt;Knowing what I know now, I can code around the problem. But still ... very curious.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 30 Aug 2016 06:58:33 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186438#M7910</guid>
      <dc:creator>Todd H.4</dc:creator>
      <dc:date>2016-08-30T06:58:33Z</dc:date>
    </item>
    <item>
      <title>Re: files/get_metadata has incorrect case for path_display</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186439#M7911</link>
      <description>&lt;P&gt;Thanks for following up with that Todd. That behavior is expected.&amp;nbsp;Dropbox itself is case-insensitive, with attempts to be case-preserving. However, due to various specifics, the API can't always return the expected case for every path component. So, for any file or folder metadata, the filename/last path component should have the preserved case, but other path components are not guaranteed to.&lt;/P&gt;
&lt;P&gt;We realize this is non-ideal of course and are looking into ways to improve it, but I don't have a solution to offer right now.&lt;/P&gt;
&lt;P&gt;If you need the preserved casing, you'll need to build it up from the last component in each parent entry.&lt;/P&gt;</description>
      <pubDate>Tue, 30 Aug 2016 07:35:14 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186439#M7911</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2016-08-30T07:35:14Z</dc:date>
    </item>
    <item>
      <title>Re: files/get_metadata has incorrect case for path_display</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186440#M7912</link>
      <description>&lt;P&gt;For reference, the known issue with lowered path_display values for deleted files in particular should be fixed now.&lt;/P&gt;</description>
      <pubDate>Wed, 14 Sep 2016 03:55:28 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/files-get-metadata-has-incorrect-case-for-path-display/m-p/186440#M7912</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2016-09-14T03:55:28Z</dc:date>
    </item>
  </channel>
</rss>

