git.sur5r.net Git - freertos/blob - FreeRTOS/Demo/Common/FileSystem/FatFs-0.7e/doc/en/sync.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">\r
   2 <html lang="en">\r
   3 <head>\r
   4 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">\r
   5 <meta http-equiv="Content-Style-Type" content="text/css">\r
   6 <link rel="up" title="FatFs" href="../00index_e.html">\r
   7 <link rel="stylesheet" href="../css_e.css" type="text/css" media="screen" title="ELM Default">\r
   8 <title>FatFs - f_sync</title>\r
   9 </head>\r
  10 \r
  11 <body>\r
  12 \r
  13 <div class="para">\r
  14 <h2>f_sync</h2>\r
  15 <p>The f_sync function flushes the cached information of a writing file.</p>\r
  16 <pre>\r
  17 FRESULT f_sync (\r
  18   FIL* <em>FileObject</em>     /* Pointer to the file object */\r
  19 );\r
  20 </pre>\r
  21 </div>\r
  22 \r
  23 <div class="para">\r
  24 <h4>Parameter</h4>\r
  25 <dl class="par">\r
  26 <dt>FileObject</dt>\r
  27 <dd>Pointer to the open file object to be flushed.</dd>\r
  28 </dl>\r
  29 </div>\r
  30 \r
  31 \r
  32 <div class="para">\r
  33 <h4>Return Values</h4>\r
  34 <dl class="ret">\r
  35 <dt>FR_OK (0)</dt>\r
  36 <dd>The function succeeded.</dd>\r
  37 <dt>FR_DISK_ERR</dt>\r
  38 <dd>The function failed due to an error in the disk function.</dd>\r
  39 <dt>FR_INT_ERR</dt>\r
  40 <dd>The function failed due to a wrong FAT structure or an internal error.</dd>\r
  41 <dt>FR_NOT_READY</dt>\r
  42 <dd>The disk drive cannot work due to no medium in the drive or any other reason.</dd>\r
  43 <dt>FR_INVALID_OBJECT</dt>\r
  44 <dd>The file object is invalid.</dd>\r
  45 </dl>\r
  46 </div>\r
  47 \r
  48 \r
  49 <div class="para">\r
  50 <h4>Description</h4>\r
  51 <p>The f_sync function performs the same process as f_close function but the file is left opened and can continue read/write/seek operations to the file. This is suitable for the applications that open files for a long time in write mode, such as data logger. Performing f_sync of periodic or immediataly after f_write can minimize the risk of data loss due to a sudden blackout or an unintentional disk removal. However f_sync immediataly before f_close has no advantage because f_close performs f_sync in it. In other words, the differnce between those functions is that the file object is invalidated or not. </p>\r
  52 </div>\r
  53 \r
  54 \r
  55 <div class="para">\r
  56 <h4>QuickInfo</h4>\r
  57 <p>Available when <tt>_FS_READONLY == 0</tt>.</p>\r
  58 </div>\r
  59 \r
  60 \r
  61 <div class="para">\r
  62 <h4>See Also</h4>\r
  63 <p><tt><a href="close.html">f_close</a></tt></p>\r
  64 </div>\r
  65 \r
  66 <p class="foot"><a href="../00index_e.html">Return</a></p>\r
  67 </body>\r
  68 </html>\r