[bug] On Android, writing to a file on Google Drive does not occur, and no error is raised

[aiueo13]

On Android, when selecting a file on Google Drive through the dialog plugin and obtaining a std::fs::File from the fs plugin’s tauri_plugin_fs::Fs::open, writing to it completes without any errors. But the changes are not reflected on the Google Drive side. In other words, data loss can occur with the silent error.

Reproduction

First, Create a new Tauri project. Since the code changes are only on the Rust side, the frontend config can be anything.

Second, add the following to [dependencies] in src-tauri/Cargo.toml.

tauri-plugin-fs = "2"
tauri-plugin-dialog = "2"

Next, replace the entire src-tauri/lib.rs with the following.

// Learn more about Tauri commands at https://tauri.app/develop/calling-rust/
#[tauri::command]
async fn greet(name: &str, app: tauri::AppHandle<impl tauri::Runtime>) -> tauri::Result<String> {
    use std::io::Write as _;
    use tauri_plugin_fs::{FsExt as _, OpenOptions};
    use tauri_plugin_dialog::DialogExt as _;

    let path = app.dialog()
        .file()
        .set_file_name("test.txt")
        .blocking_save_file();

    let Some(path) = path else {
        return Ok(format!("File unselected!"))
    };

    let mut file = app.fs().open(
        path, 
        {
            let mut option = OpenOptions::new();
            option.write(true);
            option
        }
    )?;
    
    file.write_all("test text".as_bytes())?;
    file.sync_all()?;

    Ok(format!("Success"))
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_opener::init())
        .plugin(tauri_plugin_dialog::init())
        .plugin(tauri_plugin_fs::init())
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Then, build this project and install the app on an Android device or emulator. After that, make sure that the Google Drive app is installed on the device and you are signed in. Open the app and press the greet button, which will open the file saver and prompt you to select a file. At this point, select a file on Google Drive. According to the code above, test text should be written to the selected file; however, the file remains 0 bytes on Google Drive. Please also verify that if you select a file from another app or from local storage, test text is written correctly.

[aiueo13]

Regarding this issue, I have found a solution that does not involve any breaking changes. However, I am not sure whether it would be accepted, so instead of submitting a PR, I would like to describe it here in this issue. If it seems acceptable, I will create a PR. To that end, I will first outline my understanding of Tauri’s current behavior and the findings from my investigation.
Since I am using a translation tool, please feel free to ask if anything is unclear.

It appears that this issue is occurring in projects outside of Tauri as well.

• https://stackoverflow.com/questions/51015513/fileoutputstream-writes-0-bytes-to-google-drive
• https://stackoverflow.com/questions/51490194/file-written-using-action-create-document-is-empty-on-google-drive-but-not-local
• https://community.latenode.com/t/csv-export-to-google-drive-results-in-empty-file-but-local-storage-works-fine

These also include possible workarounds, and according to them, writing via ContentResolver.openOutputStream works correctly. I tested this myself, and it indeed worked as expected. In other words, writing to a file on Google Drive succeeded.

Currently, Tauri calls ContentResolver.openAssetFileDescriptor when opening a file, detaches the file descriptor from it, passes that to Rust as a std::fs::File, and performs writes through the file descriptor.

Simplifying the issue, it seems that switching to openOutputStream would resolve it. However, this method returns a write-only stream, which corresponds to std::io::Write in Rust. This means that the data to be written would need to be passed from Rust to Kotlin, making it impractical both in terms of performance and implementation.

So this creates a twofold conflict.

• First, to maintain consistency with other platforms and avoid breaking changes to the API, it is necessary to obtain a file descriptor, which requires using openAssetFileDescriptor.

• Second, to avoid unintended silent failures, writing via openOutputStream is necessary, but this approach does not provide a file descriptor.

To resolve this conflict, I discovered StorageManager.openProxyFileDescriptor.

It creating a virtual file by providing the file access mode (readonly, writeonly, etc.) along with callbacks for writing, reading, getting the file length, fsync, and so on, and obtaining a file descriptor for it.
So this enables both writing via openOutputStream and obtaining a file descriptor for std::fs::File.

Implementation

/**
 * This is basically the same as `ContentResolver.openAssetFileDescriptor`,
 * but with a few inner modifications.
 */
@Suppress("Recycle")
fun openFd(uri: Uri, mode: String, ctx: Context): ParcelFileDescriptor {
    if (isWritableMode(mode) && needWriteViaOutputStream(uri)) {
        return openWritableFdViaOutputStream(uri, mode, ctx)
    }
    
    return ctx.contentResolver
        .openAssetFileDescriptor(uri, mode)
        ?.parcelFileDescriptor
        ?: throw IllegalArgumentException("Failed to open file: $uri")
}

private fun openWritableFdViaOutputStream(uri: Uri, mode: String, ctx: Context): ParcelFileDescriptor {
    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
        throw IllegalArgumentException("Unsupported URI: $uri")
    }

    val openAfd = {
        ctx.contentResolver
            .openAssetFileDescriptor(uri, mode)
            ?: throw IllegalArgumentException("Failed to open file: $uri")
    }

    val output: FileOutputStream
    val outputInitLen: Long
    val append: Boolean
    when (mode) {
        "w" -> {
            // NOTE:
            // Until Android 10, "w" mode will always truncate existing contents.
            // Since Android 10, "w" mode will or will not truncate existing contents.
            // - https://issuetracker.google.com/issues/180526528

            val fd = openAfd()
            val len = try { fd.length } catch (_: Exception) { UNKNOWN_LENGTH }
            outputInitLen = len
            append = false
            output = fd.createOutputStream()
        }
        "wt" -> {
            val fd = openAfd()
            outputInitLen = 0
            append = false
            output = fd.createOutputStream()
        }
        "wa" -> {
            val fd = openAfd()
            val len = try { fd.length } catch (_: Exception) { UNKNOWN_LENGTH }
            outputInitLen = len
            append = true
            output = fd.createOutputStream()
        }
        else -> throw IllegalArgumentException("Unsupported mode: $mode")
    }

    val sm = ctx.getSystemService(Context.STORAGE_SERVICE) as StorageManager

    return sm.openProxyFileDescriptor(
        ParcelFileDescriptor.MODE_WRITE_ONLY,
        UnseekableWriteOnlyFileBehaviorWithOutputStream(output, outputInitLen, append) {
            SingleThreadHandlerManager.notifyTaskEnd()
        },
        SingleThreadHandlerManager.getHandlerAndNotifyTaskAdd()
    )
}

private fun isWritableMode(mode: String): Boolean {
    // Mode is one of: r, rw, w, wa, wt, rwt
    return mode == "w" || mode == "wt" || mode == "wa" || mode == "rw" || mode == "rwt"
}

private fun needWriteViaOutputStream(uri: Uri): Boolean {
    // Returns true if the file is on Google Drive.
    // - https://github.com/tauri-apps/plugins-workspace/issues/3109
    return uri.scheme == ContentResolver.SCHEME_CONTENT
            && uri.authority?.startsWith("com.google.android.apps.docs") == true
}

@RequiresApi(Build.VERSION_CODES.O)
private class UnseekableWriteOnlyFileBehaviorWithOutputStream(
    private val output: OutputStream,
    private val outputInitLen: Long,
    private val append: Boolean,
    private val onRelease: (() -> Unit)?
) : ProxyFileDescriptorCallback() {

    private var writtenLen: Long = 0

    override fun onRead(offset: Long, size: Int, data: ByteArray): Int {
        throw ErrnoException("read", OsConstants.EBADF)
    }

    override fun onWrite(offset: Long, size: Int, data: ByteArray?): Int {
        try {
            if (offset < 0 || size < 0) throw ErrnoException("write", OsConstants.EINVAL)

            // If `append` is enabled, it behaves the same as the O_APPEND flag.
            // That is, data is always written to the end of the file, regardless of the current seek position.
            // So, skip the seek check and ignore the offset in that case.
            if (!append) {
                // Forbid file seeking
                //
                // Since seeking is not possible,
                // if not in append mode,
                // write operations start at position 0 and advance by the just amount written.
                // So the offset should match the number of bytes written since the file was opened.
                // Otherwise, it implies that a seek operation has occurred.
                if (offset != writtenLen) {
                    throw ErrnoException("write", OsConstants.ESPIPE)
                }
            }

            if (data == null) return 0
            if (data.isEmpty()) return 0
            if (size == 0) return 0

            val writeSize = size.coerceAtMost(data.size)
            output.write(data, 0, writeSize)
            writtenLen += writeSize

            return writeSize
        }
        catch (e: ErrnoException) {
            throw e
        }
        catch (e: Exception) {
            throw ErrnoException("write", OsConstants.EIO, e)
        }
    }

    override fun onFsync() {
        try {
            output.flush()
        }
        catch (e: ErrnoException) {
            throw e
        }
        catch (e: Exception) {
            throw ErrnoException("fsync", OsConstants.EIO, e)
        }
    }

    override fun onRelease() {
        try {
            output.flush()
        }
        catch (_: Exception) {}

        try {
            output.close()
        }
        catch (_: Exception) {}

        try {
            onRelease?.invoke()
        }
        catch (_: Exception) {}
    }

    override fun onGetSize(): Long {
        if (outputInitLen < 0) {
            return UNKNOWN_LENGTH
        }

        return if (append) {
            outputInitLen + writtenLen
        } else {
            // Since seeking is not possible,
            // if not in append mode,
            // write operations start at position 0 and advance by the just amount written.
            // So, the file size will never be smaller than it was when the file was opened.
            max(outputInitLen, writtenLen)
        }
    }
}

private class SingleThreadHandlerManager {
    companion object {
        private var handlerThread: HandlerThread? = null
        private var handler: Handler? = null
        private var taskCount = 0

        @Synchronized
        fun getHandlerAndNotifyTaskAdd(): Handler {
            taskCount++
            handlerThread?.let { thread ->
                val currentHandler = handler
                if (thread.isAlive && currentHandler != null) return currentHandler
            }

            handlerThread = HandlerThread("ProxyFDThread").apply { start() }
            handler = Handler(handlerThread!!.looper)
            return handler!!
        }

        @Synchronized
        fun notifyTaskEnd() {
            taskCount--
            if (taskCount <= 0) {
                handlerThread?.quitSafely()
                handlerThread = null
                handler = null
                taskCount = 0
            }
        }
    }
}

This seems perfect, but there is one concern.

openOutputStream returns a one-way write-only stream that does not support seeking, while openProxyFileDescriptor defines a file that is seekable, and there is no way to disable seeking. To resolve this inconsistency, the code above returns an error when a write operation is attempted at an unexpected offset—that is, when a seek has occurred.

From the perspective of std::fs::File user, calling std::io::Seek will appear to succeed, but any subsequent write after seeking will result in an error.

As an amateur developer, I personally believe this is preferable to silent data corruption, but I am not sure whether this behavior is acceptable from a general or semantic standpoint.

Would this be acceptable?

[aiueo13]

There is another solution as well.

By adding the flag EXTRA_LOCAL_ONLY to the file picker, we can prevent users from selecting files from Google Drive in the first place. This flag can be applied to both ACTION_GET_CONTENT (used as the file picker in the dialog plugin) and ACTION_CREATE_DOCUMENT (used as the file saver). (In the dialog plugin, the directory picker is not supported on Android.)

However, this flag is quite restrictive, and on my device it prevented selecting files from third-party apps.

FilePicker before applying LOCAL_ONLY (left) and after applying LOCAL_ONLY (right)

[aiueo13]