thswlsqls opened a new issue, #9506: URL: https://github.com/apache/paimon/issues/9506
**Search before asking** - [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. **Paimon version** master @ da71a6697 (2.1-SNAPSHOT) **Compute Engine** Engine-agnostic (Hadoop FileSystem SDK, `paimon-vfs-hadoop`) **Minimal reproduce step** `PaimonVirtualFileSystem.initialize()` (paimon-vfs/paimon-vfs-hadoop/src/main/java/org/apache/paimon/vfs/hadoop/PaimonVirtualFileSystem.java line 70) sets `workingDirectory = new Path(uri)` from the raw URI Hadoop passes in, while line 74 normalizes `this.uri` to `scheme://authority/`. Following the documented usage in `docs/docs/concepts/rest/pvfs.md` lines 61-62: ```java Path path = new Path("pvfs://catalog/db_a/tbl_a/a.csv"); FileSystem fs = path.getFileSystem(conf); fs.create(new Path("db_b/tbl_b/b.csv")); ``` **What doesn't meet your expectations?** Expected: the working directory is the catalog root, so a relative path resolves under the table it names. Actual: the instance contradicts itself — `getUri()` returns `pvfs://catalog/` but `getWorkingDirectory()` returns `pvfs://catalog/db_a/tbl_a/a.csv`. The `create` above raises no exception and writes into `db_a/tbl_a`. **Anything else?** Which table receives the write is non-deterministic: the Hadoop FileSystem cache key is scheme+authority+ugi, so it depends on which path first opened a pvfs FileSystem in that JVM. **Are you willing to submit a PR?** - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
