title: "File exists, but cannot be read", but third try is a charm (with emacs, os-x Catalina 10.15.6, dropbox smart sync)
body: <p>I try to open a file using emacs c-x c-f /Users/fred/Dropbox/foo/bar/bam/baz.txt.</p>
  <p>In the mini buffer it says...</p>
  <p>&quot;File exists, but cannot be read&quot;.</p>
  <p>...Next I do m-x revert buffer.  Now in the mini buffer it says....</p>
  <p>&quot;Opening input file: Input/output error, /Users/fred/Dropbox/foo/bar/bam/baz.txt&quot;</p>
  <p>...I do m-x revert buffer again and this time the file reads in fine.</p>
  <p>The problem is that a file should open on the first try, no questions asked!</p>
  <p>This is more or less a repeatable problem (specifically I have gotten &quot;File exists, but cannot be read&quot; several times in the last 2 weeks.  I try various work arounds to open the file (e.g. hit m-x revert buffer twice as described above).  I usually (always?) am able to open the file.  And once I finally DO open one of those obstinate files, it easily opens using emacs in other contexts (e.g. new windows, or re-opens when I have closed the buffer).</p>
  <p>&lt;&lt;&lt; UPDATE ~2 DAYS AFTER ORIGINAL POST -- START OF SECTION &gt;&gt;</p>
  <p>I seem to be able to reproduce a <em>very similar behavior</em> when I start emacs using an init file that starts an emacs with about 30 different text files open.  (I.e. part of the init is to open these files in emacs).  When I change the emacs buffer (c-x b) to point to some files, call them GoodFile1, GoodFile2, there text is visible, i.e. all is well.  For other files, call them BadFile1, BadFile2, BadFile3, when I switch to them the screen is blank and I know they have LOTs of text in them. I haven't seem any error messages akin to &quot;File exists, but cannot be read&quot;, but still this is bad behavior and it seems related to the original problem.  Next, similar to the originally reported case, I hit m-x revert buffer between 1 and 4(?) times and, poof!, the text appears and I am begrundgingly happy again.  Now, here's the interesting bit: when I start a <em>new</em> terminal window and fire up an emacs loading the same init file then the formerly bad files (e.g. BadFile1, BadFile2, BadFile3) are now visible right from the start -- as they should be on a normally functioning computer.  It is as if a formerly blank seeming file changes some sort of state so that when a fresh emacs tries to open it the file shows up as it should.  What kind of state change is involved?  I think it has to do with smart sync.  So the question is, assuming it is smart sync, how to avoid this annoying required behavior of hitting revert buffer a buncha times?  Does it last between boots?  I am pretty sure unix touch  did not help.  Maybe there is some other operation to perform?</p>
  <p>Note: On this machine I always start emacs with 'emacs -nw -l my_special_emacs_init.el' (GUI's are for wimps (-;)</p>
  <p>&lt;&lt;&lt; UPDATE ~2 DAYS AFTER ORIGINAL POST -- END OF SECTION &gt;&gt;</p>
  <p>All annoying bad behavior happens on my <em>new</em> set up.</p>
  <p>On my old setup, I have <em>never</em> gotten any thing like this behavior over years, possibly decades. (and, on my old setup, I tried the specific file mentioned above and it opened fine)</p>
  <p>So, what, you may ask, is different between my new setup and my old setup?</p>
  <ol>
  <li><p>OS / Hardware:</p>
  <ul>
  <li>New Setup: Catalina 10.15.6 on a brand new Mac Book Pro.</li>
  <li>Old Setup: Mohave 10.14.6 on a Mac Book Pro &quot;early 2015&quot; (and has never had this issue in prior OS's either)</li>
  </ul>
  </li>
  <li><p>Dropbox:</p>
  <ul>
  <li><p>New Setup: Smart Sync On.  I am using Dropbox with Smart Sync Turned on such that files are by default &quot;online only&quot;.   &quot;online only&quot; is a misnomer.  Some files end up locally on my hard drive.  Smart sync seems to figure out what files to store locally on the mac.  I suspect that knowing how it does this will fix my problem.</p>
  </li>
  <li><p>Old Setup: Smart Sync Off.  I have been using Dropbox for years but have stayed far away from Smart Sync and have never had a problem opening a file.</p>
  </li>
  </ul>
  </li>
  <li><p>Emacs Version:</p>
  <ul>
  <li>New Setup: GNU Emacs 27.1</li>
  <li>Old Setup: GNU Emacs 22.1.1.</li>
  </ul>
  </li>
  </ol>
  <p>Clearly it can't be a permissions issue bc I've never had this problem on my old setup.</p>
  <p>Any clues?</p>
  <p>Does anyone know of any diagnostics I can do to &quot;dig under the hood&quot; when I find another case of this &quot;File exists, but cannot be read&quot;.</p>
  <p>Any thoughts on whether it is OS difference?  Hardware difference?  Dropbox Smart Sync Yes vs Smart Sync No difference? Emacs version difference?</p>
  <p>&lt;&lt;&lt; UPDATE ~2 DAYS AFTER ORIGINAL POST -- START OF SECTION &gt;&gt;
  My current hunch is the the 'state change' mentioned in the update above is related to smart sync somehow figuring out that the user wants a given file cached locally.  The bad behaving files are non-local so poor emacs can't open them.  Whacking them with 1 to 4 revert buffers tells smart sync to make the given file local.  Alas, smart sync is not smart enough to figure out what emacs users want right off the bat!  Perhaps emacs can be changed in such a way as to tickle smart sync into realize that the given file should be made local local   Or we can petition Dropbox to respect emacs.  Or I am not using smart sync correctly.  Thoughts?
  &lt;&lt;&lt; UPDATE ~2 DAYS AFTER ORIGINAL POST -- END OF SECTION &gt;&gt;</p>