Design issue local-data:// files part of multiple filesystems

[digitalpoint]

Affected version

2.3

Have been running into a problem with the local-data filesystem being inside the the data filesystem. Specifically, $dataAdapter->listContents() (which lists all the files in the data directory) is now including files that are in the local-data:// filesystem. Because, well... it is.

Is it really the best idea to put a unique filesystem as a subdirectory of another filesystem like that (especially one where it's intended purpose is to never be part of it's parent filesystem)? Now we have a problem migrating files between different filesystems. Say for example you want to migrate data:// to R2 (or anything)... you move the files and delete them from the local filesystem... oh but wait, we just moved and deleted the local directory too since it's also part of the data:// filesystem.

Yes, of course you can code for exceptions, but filtering files that are part of the data:// filesystem (but really they aren't) is starting to feel hacky to me.

 

[Chris D]

We do have nested mounts already. For example code-cache://. I think the issue potentially exists already there (and has done since 2.0.0), but of course it is trivial to re-generate code_cache. At least currently the only use case for local-data is icons - which was out of technical necessity - but they are also trivially regenerated.

The main issue is we don't like the idea of introducing more mount points outside of data and internal_data because these are the only directories we can guarantee will (should) always be writeable.

The issues surrounding introducing other writeable root directories are potentially not insurmountable, but currently, at least, neither are the issues with nesting.

We don't really have any plans to change this currently but it is at least known about. It would probably be the long grass-type future if it ever were to change though.

 

[digitalpoint]

Ya, I had the same thought with internal_data... although it's not as problematic, because personally, I think the only area of internal_data worth moving to a different filesystem is "attachments" (would be crazy to me if someone wanted to move the entire internal_data directory). But yes... exact same fundamental issue.

Like I said, it can be handled with exceptions for files that start with "local/", but I don't particularly like going down the road of exception handling and remembering all the places you need to do it if later other similar exception directories are introduced (starts to feel like WordPress or vBulletin coding, not XenForo... that's all).

Maybe (my) solution is to extend the local adapter, when a list of all files is called, spin through all XenForo adapters, see if there are others embedded within that adapter and filter out files that exist within the path of directories that are part of other adapters. That should handle current (and future) exception handling I think (hah just thinking to myself...)