Paths

Working with paths in Files.com involves several important considerations. Understanding how path comparisons are applied helps developers ensure consistency and accuracy across all interactions with the platform.

Capitalization

Files.com compares paths in a case-insensitive manner. This means path segments are treated as equivalent regardless of letter casing.

For example, all of the following resolve to the same internal path:

Path VariantInterpreted As
Documents/Reports/Q1.pdfdocuments/reports/q1.pdf
documents/reports/q1.PDFdocuments/reports/q1.pdf
DOCUMENTS/REPORTS/Q1.PDFdocuments/reports/q1.pdf

This behavior applies across:

  • API requests
  • Folder and file lookup operations
  • Automations and workflows

See also: Case Sensitivity Documentation

The PathUtils.isSame function in the Files.com SDK is designed to help you determine if two paths on your native file system would be considered the same on Files.com. This is particularly important when handling errors related to duplicate file names and when developing tools for folder synchronization.

Compare Case-Insensitive Files and Paths

import com.files.util.PathUtils;

if (PathUtils.isSame("Fïłèńämê.Txt", "filename.txt")) {
    System.out.println("Paths are the same");
}

Slashes

All path parameters in Files.com (API, SDKs, CLI, automations, integrations) must omit leading and trailing slashes. Paths are always treated as absolute and slash-delimited, so only internal / separators are used and never at the start or end of the string.

Path Slash Examples

PathValid?Notes
folder/subfolder/file.txtCorrect, internal separators only
/folder/subfolder/file.txtLeading slash not allowed
folder/subfolder/file.txt/Trailing slash not allowed
//folder//file.txtDuplicate separators not allowed

Unicode Normalization

Files.com normalizes all paths using Unicode NFC (Normalization Form C) before comparison. This ensures consistency across different representations of the same characters.

For example, the following two paths are treated as equivalent after NFC normalization:

InputNormalized Form
uploads/\u0065\u0301.txtuploads/é.txt
docs/Café/Report.txtdocs/Café/Report.txt
  • All input must be UTF‑8 encoded.
  • Precomposed and decomposed characters are unified.
  • This affects search, deduplication, and comparisons across SDKs.