StandardOpenOption

[vu lee]

I am not sure why would this option invalid since it looks legitimate to me.

new OpenOption[]{StandardOpenOption.READ, StandardOpenOption.SYNC}
This is an invalid combination.

[Stephan van Hulst]

This is just a guess, but I think to use SYNC you also need to use WRITE.

If you're supplying these options to one of Files' methods to open a file, keep in mind that you don't have to create the array, you can just use varargs.

[vu lee]

Does read option guarantee read the latest changes? Suppose it is reading in a middle of a file, and another thread make changes at the end of a file. Would read see these changes?

Should not just part of a file been lock?

[Stephan van Hulst]

If the threads are running in the same Virtual Machine, then reads are always guaranteed to see the latest writes, regardless of whether you use the SYNC option. This is assuming that the reading thread didn't buffer the file content in the mean time.

The SYNC option is only used to make sure that when your write operations return, the data is indeed written to the underlying storage device, but only if it's a local device. It has nothing to do with visibility of written data, and can not be used to guarantee that different programs on the same machine see each other's writes.

[vu lee]

since going through a kernel to get file content is costly, avoid buffer would be expensive. Since level stream API uses buffer, we cannot make that assumption. That s why I think read and sync are valid option.

[Stephan van Hulst]

Like I said, SYNC is unrelated to that problem.

If you're using multiple threads at the same time to read and write to a file, and you're using buffering, then it's simply not possible to guarantee that your reads see the latest updates to the file.

[vu lee]

This is about whether read and sync are valid. If it is not valid, it is sort of a dirty read.

[Stephan van Hulst]

Using only READ and SYNC together doesn't make sense, because SYNC only relates to WRITE operations.