Unified Path System

New in v8, FluentStorage introduces a simple unified path system. Users work with the same path format across all storage providers, without having to deal with provider-specific path details.

The idea is to allow users to write app logic against one storage abstraction. Start with local disk, switch to S3, Azure Blob, GCP, or SFTP later, without changing any app logic.

Unified path format

FluentStorage paths are always:

1. Relative paths
2. Parts are separated by /
3. Does not start or end with /

Do not write: /home/user/uploads/images/cute.png, instead write images/cute.png and it will map to the correct location appropriately.

Provider differences are handled internally

Different storage systems have different path rules:

Provider	FluentStorage path	Provider path
S3 / S3-compatible storage	images/logo.png	images/logo.png
Azure Blob Storage	images/logo.png	images/logo.png
Google Cloud Storage	images/logo.png	images/logo.png
Disk-based storage	images/logo.png	C:\Storage\images\logo.png
SFTP	images/logo.png	/Storage/images/logo.png

Root directories

Local Disk and SFTP can have a configured root directory, allowing an input path of images/cute.png to write to /home/user/uploads/images/cute.png.

FTP does not have a root directory, because all FTP connections have a "working directory" that can be set instead.

Path normalization

Every API call automatically normalizes the given object path or file path using StoragePath.Normalize. This guarantees that all paths inside FluentStorage follow the unified path system, regardless of what format the caller provides.

Examples:

Input path	Normalized path
users/123/profile.jpg	users/123/profile.jpg
/users/123/profile.jpg	users/123/profile.jpg
\users\123\profile.jpg	users/123/profile.jpg
users//123///profile.jpg	users/123/profile.jpg
/	""
""	""

StoragePath.Normalize does the following:

• Converts \ separators to /
• Removes leading /
• Removes trailing /
• Removes duplicate separators
• Converts empty/root paths to ""

Benefits

This unified path system is critical to supporting a polycloud API without forcing devs to hard-code different path handling when switching to different providers. It provides many benefits:

• One path format across all storage providers
• No provider-specific path handling
• Easy switching between storage backends
• Consistent behavior across local and cloud storage
• Fewer path-related bugs
• Simpler testing
• Easier addition of new storage providers
• Less code duplication
• Better long-term maintainability