rolled back: the java process sees the directory as cleared, but it's not and the files are still there when gradle exits.

Only

--no-daemon

makes it work as expected.

Basically my task populates a directory after clearing it. The populating works, but not the clearing, and I end up with old and new files in the directory.

It does!

So something in F2FS breaks the virtual-fs of gradle, should I report that somewhere ?

Ah, maybe something interesting:

2022-04-04T18:32:50.668+0200 [DEBUG] [org.gradle.internal.vfs.impl.AbstractVirtualFileSystem] Invalidating VFS paths: [/home/java/javafx-sample/build/native]

That is the offending directory.

You can try

lsof

to find if it's the case

Linux does physically deletes the file when no more process access it, but the files should not be listed anyway in

ls

if it was the reason, I believe.

--info

prints:

Not watching /home/java/javafx-sample since the file system is not supported
Watching the file system is configured to be enabled if available
File system watching is active

If that may help: the directory is marked as

@OutputDirectory

, if I replace the annotation with

@Internal

, it works

oops, sorry, forget this, it doesn't work either.

Raah... now it fails on ext4 too. The only situation where it works for sure is with

--no-daemon

All happen as if the daemon vfs didn't record the deletion and the files pop back when it syncs with the concrete fs

Sorry, I misled you. The problem seems finally related to the fact that the files in the directory are native libraries, loaded from the build script, in specific class loaders, but when using the daemon the class loaders linger in the daemon (before being GC one day) and the native libraries stay loaded.

When running with

--no-daemon

the libs are unloaded when the JVM dies. Not sure how to solve this though.