EnsoFile uses java.nio.files.Path instead of TruffleFile

[Akirathan]

Partially fixes #14122

Pull Request Description

Refactors EnsoFile to use java.nio.files.Path instead of TruffleFile.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[JaroslavTulach]

Few more truffle boundaries needed... Done in 564907e

[JaroslavTulach]

OK, in general. We do want to move away of using TruffleFile, because it makes little sense when one can polyglot java import java.io.File... The primary use of TruffleFile is security and Enso as deliberately given upon any security by opening whole JDK API up.

The Windows failures may be relevant and may deserve to be addressed.

❌ Read XLSX / XLS Files
❌ during read_many, should not mix metadata columns with data columns with same name or when matching by position
An unexpected dataflow error ((Access_Denied (File_Like.Value (File C:\runner_work\enso\enso\test\Table_Tests\data\transient\read_many_test)))) has been matched (at C:\runner_work\enso\enso\test\Table_Tests\src\IO\Read_Many_Spec.enso:452:5-46).
❌ during read_many, should correctly handle empty sheets
An unexpected dataflow error ((Access_Denied (File_Like.Value (File C:\runner_work\enso\enso\test\Table_Tests\data\transient\read_many_test)))) has been matched (at C:\runner_work\enso\enso\test\Table_Tests\src\IO\Read_Many_Spec.enso:452:5-46).

[Akirathan]

The stack trace of java.io.AccessDeniedException on Windows is at https://github.com/enso-org/enso/actions/runs/18405614769/job/52448768751?pr=14126#step:14:6652 when trying to create a directory after it has been recursively deleted. This exception is thrown from

enso/test/Table_Tests/src/IO/Read_Many_Spec.enso

Line 452 in 9422ebb

base_dir.create_directory . should_succeed

This exception is happening both in JVM mode and in native mode. On Windows only.

GitHub

EnsoFile uses java.nio.files.Path instead of TruffleFile · enso-org/enso@78d78b2

Enso Analytics is a self-service data prep and analysis platform designed for data teams. - EnsoFile uses java.nio.files.Path instead of TruffleFile · 78d78b2

[Akirathan]

Executing just a single test on Windows that was previously failing (along with some additional log messages) is (surprisingly) OK - https://github.com/enso-org/enso/actions/runs/19165386957/job/54789759488?pr=14126#step:14:914. Let's try to run two consecutive tests - 2adea49

GitHub

EnsoFile uses java.nio.files.Path instead of TruffleFile · enso-org/enso@7609480

Enso Analytics is a self-service data prep and analysis platform designed for data teams. - EnsoFile uses java.nio.files.Path instead of TruffleFile · 7609480

[Akirathan]

After adding more verbose logs in da7a7a6, running two consecutive tests now mysteriously pass. The AccessViolationException was expected to be thrown in https://github.com/enso-org/enso/actions/runs/19178063595/job/54832637621?pr=14126#step:14:1279 that is, when creating the directory after it has been recursively deleted. The previous AccessViolationException is in https://github.com/enso-org/enso/actions/runs/19167793456/job/54796541791?pr=14126#step:14:933

More verbose logs revealed, that all the EnsoInputStream and EnsoOutputStream are properly closed.

[Akirathan]

Since the AccessDeniedException occurs transiently, my latest theory is that there is some kind of race condition, similar to the one mentioned in https://stackoverflow.com/questions/15892295/access-denied-when-repeatedly-create-and-remove-the-same-directory. I have tested this theory on Akirathan/windows-nio#1 but without success. In that PR, there is a recursively deleted directory, and then created, in a loop.

Stack Overflow

Access denied when repeatedly create and remove the same directory

I just had a little test, and this is how I did it: I repeatedly create and remove one directory, d:\test, for example. I did that for like 1000 times, and it always will get an error for acccessing

[Akirathan]

After an investigation, that has taken longer than I expected, I have simply decided that the AccessDeniedException is most likely caused by some race condition on Windows. As such, I am providing a simple retry mechanism directly in the test in 1826dc7.

I think this is OK because end users are unlikely to delete and create the same directory in a tight loop. And if so, and the AccessDeniedException is raised, we can argue that is an "expected weird behavior of Windows". At this time, I don't think there is any reasonable systematic solution for this problem.

[JaroslavTulach]

• won't the problems go away if 524405f stops using the same directory again and again?
• if not, feel free to remove 524405f with git reset HEAD~1; git push -f

[Akirathan]

Thanks. I think this is a much more elegant solution. And yes, the problem should go away. Let's merge.