Missing Folders on Remote Mounts

Remote Server Mounts reflect the structure of a remote system inside Files.com. A folder that was previously visible through a mount may be moved, deleted, or temporarily inaccessible on the remote system without going through Files.com. When that happens, Files.com defers cleanup so that transient remote-side issues don't destroy Automations, permissions, Folder Settings, and other configuration tied to the folder.

This handling applies only to changes detected on the remote system. Folders deleted through Files.com are removed immediately, along with their associated metadata.

Why Missing Folders Are Hard to Interpret

When Files.com interacts with a remote mount, it relies on the remote system's APIs to list and access files and folders. Those APIs are not always reliable. Transient network conditions can cause a file or folder to appear missing even though it still exists on the remote system.

If Files.com deleted local metadata the moment a folder appeared missing, these temporary conditions would break Automations, drop permissions, and lose configured Folder Settings on folders that later reappear unchanged.

How Files.com Handles Missing Folders

When Files.com detects that a file or folder on a remote mount is missing during a list or lookup operation, it does not delete the corresponding local metadata. It records the missing path and places it in a deferred deletion queue. Over a 72-hour validation window, background processes periodically recheck the path against the remote system.

If the folder or file is confirmed to exist again during this window, Files.com stops checking the missing path and makes no changes. Permissions, Folder Settings, notifications, and other associated configuration remain intact.

If the folder or file continues to be missing after repeated checks across the validation window, Files.com treats it as permanently removed and removes its associated metadata in the same way it would if the folder had been deleted directly through Files.com. This includes Folder Settings, permissions, notifications, and other objects tied to that folder.

This deferred approach lets Files.com distinguish between a folder that has truly been removed from the remote system and a folder that is only temporarily inaccessible. Changes made outside of Files.com do not immediately break Automations or erase configuration, and legitimate removals are reconciled after the validation window in a consistent and predictable way.