It looks like we have two mechanisms (file locks and atomic moves) to achieve same goal (exclusion).
So, what is lock needed for?

the file locks is for the exclusive - only one thread should able to create target file at a time.
The move is for the visibility(atomic), readers should either not see the target file or see the file exists and with the full content.

pls document this line of thinking with a comment

@chenjian2664 lock file is "cooperative locking" - the parties involved need to agree on the "protocol" they are following (the lock file existence, its name, locked region).
rename seems to be sufficient for "cooperative exclusion"

i.e. if there is no lock file at all, what could possibly go wrong?

@findepi The reason is Files.move is not guarantee to be exclusive it is only guarantee to be atomic.
If no lock there then probably multi-threads will think it success moved, but actually being overwrite by others-who commit last win.

I believe that Files.move with ATOMIC_MOVE and without REPLACE_EXISTING is exclusive.
At least it's IMO documented as such.

Am i wrong?

I tested with below code :

    static void main()
            throws Exception
    {
        Path tempDirectory = Files.createTempDirectory("trino-test-");
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        CyclicBarrier barrier = new CyclicBarrier(10);
        Path targetFilePath = tempDirectory.resolve("target.test");
        for (int i = 0; i < 10; i++) {
            Path tmpFilePath = tempDirectory.resolve("file-" + i + ".test");
            executorService.execute(() -> {
                try {
                    writeFile(tmpFilePath);
                    barrier.await();
                    Files.move(tmpFilePath, targetFilePath, ATOMIC_MOVE);
                    System.out.println("Moved " + tmpFilePath.getFileName() + " to target.test");
                }
                catch (Exception e) {
                    throw new RuntimeException(e);
                }
            });
        }

        Thread.sleep(5000);
        executorService.shutdown();
    }

    private static void writeFile(Path tmpFilePath)
            throws IOException
    {
        try (OutputStream out = Files.newOutputStream(tmpFilePath, CREATE_NEW, WRITE)) {
            out.write(("this is " + tmpFilePath.getFileName()).getBytes());
        }
    }

multiple tmp files think there success moved. could you please help to confirm, or I am using wrongly with the move?

You're right. I have not read Files.move lengthy javadoc carefully enough. Thanks for standing me corrected.

We may get away from this by

• call some native rename / renameat / renameat2 function. Linux kernel awesomely supports this basic operation of renaming a file without overriding a target, should it exist. It's Java's fault it doesn't work
  • not great as it's going to be some unpretty JNA / FFM call and may or may not work on MacOS & Linux the same way
• workaround the limitation with Files.createLink. It seems to deliver exclusive target creation (on MacOS at least)
  • not great as this function seems quite platform-dependent. it doesn't seem to guarantee exclusiveness
• remind ourselves we're doing this for our tests only. While LocalFileSystem is a production facility which needs to be implemented well, the only call site we're really concerned about is LocalTransactionLogSynchronizer (which was supposed to be moved to test dir). For internal test purposes we can simply synchronize in memory on a lock. BTW this is how FileHiveMetastore performs synchronization around filesystem operations.

Let's do this last option.

Sorry for the late reply.
I did consider an in-memory lock at first. My concern is about how we validate the log synchronizer design. We're currently relying entirely on the semantics of createExclusive and assuming the synchronizer logic is correct.

If we can't prove the local concurrency behavior is correct, how can we trust it in the cloud, even if the filesystem provides the same createExclusive guarantees, that’s why I wanted this to work across multiple clusters. It's still not a strong guarantee, but at least it would give us some confidence that matching createExclusive semantics won't lead to corrupted Delta logs or wrongly thinking it is success committed.

But I looked the FileHiveMetastore you've mentioned seems I am overthinking ?

And I don't found tests about the concurrent writing of cloud log synchronizer, is it because of the flaky, or I am missing the tests at somewhere, what's the reason behind?