[colug-432] Troubleshooting Suggestions: File Truncation Issue

[Brian]

If Jeff is correct, you might get around the issue by doing the writes to a
tmpfs RAM disk, rather than to a physical disk.
On Jan 10, 2016 10:32 AM, "Jeff Frontz" <jeff.frontz at gmail.com> wrote:

>
> On Sat, Jan 9, 2016 at 11:13 PM, William E. T. <linux.hacker at gmail.com>
> wrote:
>
>> 1.   Opens a new file
>> 2.  Writes to the file
>> 3.  Closes the file
>> 4.  Creates a link to its real name
>> 5.  Removes the original file
>> 6.  stats the file to find a zero size
>>
>
> Without knowing the details of the particular kernel or filesystem/RAID
> drivers involved, there  is the potential for a race condition between 2/3
> and 6.
>
> On Unix/Linux, there is no guarantee that data has ever made it to the
> "disk" (which could include the various levels of drivers/caches in between
> your program and the actual hardware).
>
> From the close(2) man page notes:
>
> " A  successful  close  does  not  guarantee that the data has been
> successfully saved to disk, as the kernel defers writes. It is not common
> for a filesystem to flush the buffers when the stream is closed. If you
> need to be sure that the data is physically stored use fsync(2).  (It will
> depend on the disk hardware at this point.)"
>
>
>
> The only guarantee of a non-zero size would be if you called fstat (note
> the "f") on the still-open file descriptor (used in 1/2/3 above).
>
> You can throw in a call to sync(2) to after the close(), though depending
> on how your I/O stack is composed even that might not be perfect.
>
> Jeff
>
>
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20160111/5709ff2e/attachment.html