thswlsqls opened a new issue, #8934:
URL: https://github.com/apache/paimon/issues/8934

   
   **Search before asking**
   - [x] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   **Paimon version**
   master @ 27f4656bb / 2.0-SNAPSHOT
   
   **Compute Engine**
   Engine-agnostic (paimon-filesystems/paimon-gs-impl)
   
   **Minimal reproduce step**
   Configure a GCS warehouse with any `gs.`-prefixed option, e.g. 
`gs.auth.type` or `gs.project.id`.
   `GSFileIO.configure()` (GSFileIO.java line 63-78) accepts prefixes `{"gs.", 
"fs.gs."}` but copies matching keys into the Hadoop configuration unchanged.
   The gcs-connector (1.9.4-hadoop3) only reads `fs.gs.*` keys, so `gs.*` 
settings are silently dropped.
   Flink's `flink-gs-fs-hadoop` `ConfigUtils`, the source of this prefix list, 
translates `gs.` to `fs.gs.`; the translation was lost in the Paimon port.
   Sibling `S3FileIO` maps `{"s3.", "s3a.", "fs.s3a."}` to `fs.s3a.*` and 
`AzureFileIO` maps its prefixes to `fs.azure.*`.
   
   **What doesn't meet your expectations?**
   Expected: `gs.x` options reach the connector as `fs.gs.x`. Actual: they are 
ignored.
   
   **Anything else?**
   No Paimon `ConfigOption` starts with `gs.` (repo grep), so the mapping has 
no side effect.
   Merely removing the `gs.` prefix would not fix existing user configs.
   Mixed `gs.x` + `fs.gs.x` input behaves like the same edge in S3/Azure (last 
write wins).
   
   **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]

Reply via email to