title: How to prevent data loss when closing a file descriptor?
body: <p>When I issue <code>write()</code>, my data goes to some kernel space buffers. The actual commit to physical layer ("phy-commit") is (likely) deferred, until.. (exactly until what events?)</p>
  
  <p>When I issue a <code>close()</code> for a file descriptor, then</p>
  
  <blockquote>
    <p>If [...], the resources associated with the open file description are freed</p>
  </blockquote>
  
  <p>Does it mean releasing (freeing) those kernel buffers which contained my data? What will happen to my precious data, contained in those buffers? Will be lost?</p>
  
  <p>How to prevent that loss?</p>
  
  <p>Via <code>fsync()</code>? It requests an explicite phy-commit. I suppose that either immediately (synchronous call) or deferred only "for short time" and queued to precede subsequent operations, at least destructive ones.</p>
  
  <p>But I do not quite want immediate or urgent phy-commit. Only (retaining my data and) not to forget doing phy-commit later in some time.</p>
  
  <p><br>
  From <code>man fclose</code>:</p>
  
  <blockquote>
    <p>The fclose() function [...] closes the underlying file descriptor.<br>
    ...<br>
    fclose() flushes only the user-space buffers provided by the C library.  To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for  example,  with  sync(2) or fsync(2).</p>
  </blockquote>
  
  <p>It may suggest that <code>fsync</code> does not have to <em>precede</em> <code>close</code> (or <code>fclose</code>, which contains a <code>close</code>), but can (even have to) come after it. So the <code>close()</code> cannot be very destructive...</p>