Limitations

Limitations

Unsupported file-system operations

The following low-level file-system operations are not supported by Cloudfuse:

• mknod
• link (hard link API)
• setxattr / getxattr / listxattr / removexattr
• access
• lock / flock
• bmap
• ioctl
• poll
• write_buf / read_buf
• fallocate
• copyfilerange
• lseek

Unsupported file-system workflows

The following higher-level file-system behaviors are not supported or are limited:

• Creation of pipes, FIFO queues, device files, or other special files (sockets, character/block devices).
• Extended attributes (xattrs) for files or directories.
• Hardlinks for files or directories.
• Accurate reporting of last access time (atime) and last change time (ctime) for files and directories.

Operations with altered behavior

Some POSIX operations behave differently under Cloudfuse:

• fsync(): Forces removal of the local cached copy and invalidates attribute metadata. The file's data and attributes will be refreshed from cloud storage on the next open.
• fsyncdir(): Invalidates metadata for the directory recursively; child metadata is refreshed from the store on the next kernel metadata request.
• rename(): Renames are non-atomic on object storage. A single-file rename is implemented as a copy followed by a delete. Directory renames iterate and rename each object under the directory.

Known differences from a native Linux filesystem

Cloudfuse maps filesystem calls to cloud object storage APIs; this results in a few important differences:

• readdir / hard link counts: For performance reasons Cloudfuse does not report POSIX hard-link counts accurately. Empty directories may report 2; non-empty directories may report 3 regardless of actual link counts.
• Non-atomic operations: Many operations that are atomic on POSIX filesystems (rename, some metadata updates) are implemented as multiple object storage operations and are therefore not atomic.
• Write-streaming / concurrent writes: Concurrent streaming reads and writes to the same object can produce unpredictable results. Avoid simultaneous writers to the same blob/object.
• chown / chmod: Cloud storage backends have different support for ownership and permissions:
  • S3 backends generally do not provide POSIX ownership/ACLs; chmod/chown semantics are limited.
  • Azure Block Blob (flat namespace): chown is not supported; chmod behavior may be ignored and Cloudfuse may return success without changing anything.
  • Azure Data Lake (HNS) supports more metadata operations than block blob accounts, but behavior can still differ from POSIX.

Unsupported scenarios

• Overlapping mount paths: Running multiple Cloudfuse instances with overlapping mount points is unsupported — ensure unique, non-overlapping mount paths.
• Co-existence with NFS: Mounting Cloudfuse on the same path as an NFS mount is not supported; behavior is undefined.
• Non-HNS Azure accounts (flat namespace): Directories are represented by marker objects. If marker objects are absent and --virtual-directory=true (or equivalent config) is not enabled, Cloudfuse may not recognize directory structure correctly.