<?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 Re: Obj-C API 2: DBFILESWriteMode - using -initWithUpdate with file revs vs -initWithOverwrite: in Dropbox API Support &amp; Feedback</title>
    <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191441#M8370</link>
    <description>&lt;P&gt;Hi Keith, for reference, yes, in API v1 it was also possible to just overwrite a file without a rev. In either though, it's generally not reccomended, as its easy to overwrite data you didn't intend to due to race conditions that way.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;1. That's correct, with autorename set to NO, the API won't attempt to find somewhere to put the file, and will just returned the conflict error. And correct, the YES behavior will successfully commit the file, just at a different path, like the API v1 behavior you describe.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;2. Yes, we definitely&amp;nbsp;recommend using update instead of overwrite, because of the potential of race conditions, as mentioned above. (E.g., if two instances of your app happen to upload new versions at about the same time, one will blow away the other version.)&lt;/P&gt;</description>
    <pubDate>Thu, 20 Oct 2016 18:57:32 GMT</pubDate>
    <dc:creator>Greg-DB</dc:creator>
    <dc:date>2016-10-20T18:57:32Z</dc:date>
    <item>
      <title>Obj-C API 2: DBFILESWriteMode - using -initWithUpdate with file revs vs -initWithOverwrite:</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191405#M8362</link>
      <description>&lt;P&gt;In API 1, to overwite an existing file on the server, it was always necessary (as I understand it) to provide the file rev of the existing file. If you didn't do this, you would receive an error. Otherwise, you had to first delete the file and then write it again. (I could be wrong about this - maybe it was possible to overwrite a file without a rev but I just never did it.)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In API 2, DBFILESWriteMode allows you to determine what will happen if a file already exists at the chosen path when trying to upload a file. You have three choices:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;a.&amp;nbsp;Update: requires the file rev. If the file rev is not provided or does not match, it will be treated as a conflict.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;b. Overwrite: always overwrites the file at the given location no matter what.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;c. Add: always creates a conflicted file if a file exists at the given location (opposite of (b)).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Two questions related to this:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1. If autorename is set to NO for the upload task, will (a) and (b) always result in an error if the file cannot be written at the selected path? (This is what I would expect: if I pass in NO&amp;nbsp;for autorename, I would not expect the frameworks to create any file if it cannot be placed at the exact specified location.)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In API 1, when uploading with a file rev, if there was a "failed to grab file locks" error or if the rev was&amp;nbsp;wrong, the file would still be uploaded but using a different (conflicted) file name, so that I had to check for that case and try to fix things up if it happened. So will&amp;nbsp;passing YES for autorename result in the same behaviour as API 1, but passing NO avoid this issue entirely and *never* result in the uploaded file using a different name ("conflict" etc)?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;2. Is there any advantage in using (a) over (b)? At the moment I am maintaining file revs and using them for uploads. Is there a good reason to continue with this approach rather than just forcing an overwrite every time I want to update an existing file?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Keith&lt;/P&gt;</description>
      <pubDate>Wed, 29 May 2019 09:29:06 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191405#M8362</guid>
      <dc:creator>Keith B.7</dc:creator>
      <dc:date>2019-05-29T09:29:06Z</dc:date>
    </item>
    <item>
      <title>Re: Obj-C API 2: DBFILESWriteMode - using -initWithUpdate with file revs vs -initWithOverwrite:</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191441#M8370</link>
      <description>&lt;P&gt;Hi Keith, for reference, yes, in API v1 it was also possible to just overwrite a file without a rev. In either though, it's generally not reccomended, as its easy to overwrite data you didn't intend to due to race conditions that way.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;1. That's correct, with autorename set to NO, the API won't attempt to find somewhere to put the file, and will just returned the conflict error. And correct, the YES behavior will successfully commit the file, just at a different path, like the API v1 behavior you describe.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;2. Yes, we definitely&amp;nbsp;recommend using update instead of overwrite, because of the potential of race conditions, as mentioned above. (E.g., if two instances of your app happen to upload new versions at about the same time, one will blow away the other version.)&lt;/P&gt;</description>
      <pubDate>Thu, 20 Oct 2016 18:57:32 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191441#M8370</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2016-10-20T18:57:32Z</dc:date>
    </item>
    <item>
      <title>Re: Obj-C API 2: DBFILESWriteMode - using -initWithUpdate with file revs vs -initWithOverwrite:</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191445#M8373</link>
      <description>Great, thanks!</description>
      <pubDate>Thu, 20 Oct 2016 19:05:03 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Obj-C-API-2-DBFILESWriteMode-using-initWithUpdate-with-file-revs/m-p/191445#M8373</guid>
      <dc:creator>Keith B.7</dc:creator>
      <dc:date>2016-10-20T19:05:03Z</dc:date>
    </item>
  </channel>
</rss>

