Hierarchical Namespace

The Use Hierarchical Namespace (Azure Data Lake Storage Gen2) setting applies to Azure Blob Storage when using it as a Remote Server.

Enable this option when your Azure storage account uses Azure Data Lake Storage Gen2 with hierarchical namespace enabled. With this setting on, Files.com interacts with your container using directory-aware semantics that match the storage account configuration.

Hierarchical namespace changes how Azure represents and processes folders. When this option does not match your Azure storage configuration, directory operations from Files.com fail or behave inconsistently.

Flat Namespace vs. Hierarchical Namespace

Standard Azure Blob Storage uses a flat namespace. In this model, folders are not real objects. Example: reports/2026/january.csv exists as a single object key. The reports/2026/ portion is part of the name, not a true directory.

When renaming or deleting a "folder" in a flat namespace, Azure must enumerate and process every object that shares the same prefix. This becomes inefficient for large directory trees.

With hierarchical namespace enabled, Azure stores directories as first-class entities. Directory renames and deletes execute as metadata operations instead of per-object rewrites. Directory boundaries are explicit, and Azure supports POSIX-style access control lists (ACLs).

When to Use Hierarchical Namespace in Azure Blob

Hierarchical namespace is appropriate when the Azure storage account functions as a structured data lake or supports backend analytics pipelines that depend on directory-level operations. A common workflow involves writing data to a staging directory like data/staging/job-1234/ and then renaming that directory to data/production/2026-01-01/ when the job completes. With hierarchical namespace enabled, Azure performs this rename as a single metadata update. Without it, Azure must enumerate and rewrite every object under that path.

Hierarchical namespace also supports backend directory-level permission enforcement using POSIX-style ACLs and improves efficiency when deleting large directory trees. If your workload primarily stores backups, static files, archives, or simple object data without frequent directory renames or directory-level ACL requirements, hierarchical namespace provides no operational benefit.

Permanent Storage Account Configuration

Azure does not allow disabling hierarchical namespace after it has been enabled on a storage account. This configuration permanently changes directory semantics and permission capabilities. Evaluate workload requirements before enabling hierarchical namespace in production environments.

Files.com Integration Behavior

When you enable the Use Hierarchical Namespace (Azure Data Lake Storage Gen2) option in your Remote Server configuration, Files.com uses Azure's Data Lake Storage API semantics for directory-aware operations. Folder renames and deletes initiated from Files.com execute at directory scope when the storage account supports it, and directory-level permissions follow Azure ACL behavior when configured.

If the Azure storage account has hierarchical namespace enabled but this option is not selected during Remote Server setup, directory operations from Files.com fail because the API semantics do not match the storage account configuration. For example, attempting to delete a folder returns the error Cannot delete a directory. You may need to enable 'azure_blob_storage_hierarchical_namespace' setting on your remote server if you have the hierarchical namespace feature enabled on your azure storage account.

Hierarchical namespace changes directory behavior and permission handling. It does not affect upload or download throughput.