What causes "no valid file paths to write (invalid UTF-8 or path)" in siyuan-note/siyuan?

Validate each path is valid UTF-8 before calling: skip or convert strings where !utf8.ValidString(p)

no valid file paths to write (invalid UTF-8 or path)

Error message

no valid file paths to write (invalid UTF-8 or path)

What it means

On macOS, WriteFilePaths marshals each path to a NUL-terminated C string and calls writeFilePathsToPasteboard via cgo. The Objective-C helper returns -2 when none of the supplied paths could be converted/validated — typically invalid UTF-8 in a path or an unusable path string — so the pasteboard write is aborted.

Solutions

Validate each path is valid UTF-8 before calling: skip or convert strings where !utf8.ValidString(p)
Normalize problematic names (golang.org/x/text/encoding or unicode/norm) before clipboard write
Ensure the slice is non-empty and every element is a real filesystem path

Example fix

// before
util.WriteFilePaths(rawPaths) // contains invalid UTF-8
// after
var valid []string
for _, p := range rawPaths {
    if utf8.ValidString(p) { valid = append(valid, p) }
}
if len(valid) > 0 { util.WriteFilePaths(valid) }

Defensive patterns

Strategy: validation

Validate before calling

func allValidUTF8(paths []string) bool {
    for _, p := range paths {
        if !utf8.ValidString(p) || p == "" { return false }
    }
    return len(paths) > 0
}

Type guard

func isClipboardReadyPath(p string) bool { return p != "" && utf8.ValidString(p) }

Try / catch

if err := util.WriteFilePaths(paths); err != nil {
    if strings.Contains(err.Error(), "no valid file paths") {
        // sanitize/normalize paths and retry
    }
}

Prevention

Validate utf8.ValidString on every path before clipboard writes
Normalize filenames with unicode/norm or x/text when read from legacy filesystems
Never pass raw byte-slice-derived strings as paths without validation

When it happens

Trigger: Calling util.WriteFilePaths with a []string containing non-UTF-8 bytes (Go strings can hold arbitrary bytes) so the conversion to const char* fails for every path, or an empty/nil slice reaching the C helper.

Common situations: File names read from disk with non-UTF-8 encodings (e.g. legacy NFD/HFS+ or Latin-1 names) being pushed to the clipboard; paths built from raw byte buffers.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of siyuan-note/siyuan@9f775e8a12 (2026-09-19). Data as JSON: /api/errors/9d88e2de630b4dee. Report an issue: GitHub.

Appendix: source

Thrown at kernel/util/clipboard_darwin.go:100

		return nil
	}
	// 分配 C 的 char* 数组，便于传入 Objective-C
	cPaths := make([]*C.char, len(paths))
	for i, p := range paths {
		cPaths[i] = C.CString(p)
	}
	defer func() {
		for _, c := range cPaths {
			C.free(unsafe.Pointer(c))
		}
	}()
	// 取首元素地址作为 const char** 传入
	ret := C.writeFilePathsToPasteboard((**C.char)(unsafe.Pointer(&cPaths[0])), C.int(len(paths)))
	switch ret {
	case 0:
		return nil
	case -2:
		return errors.New("no valid file paths to write (invalid UTF-8 or path)")
	default:
		return errors.New("failed to write file paths to pasteboard")
	}
}

View on GitHub (pinned to 9f775e8a12)