As you’ve noticed, the CLI has access to an early version of backup. Most of what is unfinished here is UX feedback, but there may also be some deficiencies in exception handling. By and large, though, it should work for the basic need of periodically pushing your data to the cloud.
Extended attribute use was explored in the past for OS X (and to a lesser degree, Windows), but was decided against, at the time. Since Linux support didn’t come until quite a bit later, the existing conventions we were using for the other OSs were carried over (placeholder files). Is there anything, in particular, you had in mind for Linux?
I’ll continue to use as-is. Seems to work well. Hopefully I’m on a list somewhere which will be pinged when the backup feature is formally released.
The xattr was just an idea - I was working on something recently, and it seemed to make sense to use that sort of thing for file meta-data at this level. But the placeholder files work really well. - If you had xattr, I suppose you could name the file anything - but that would just get confusing quickly…
Not sure whether to start another topic but - I make use of network namepsaces to ensure that the odrive agent is in a QOS restricted environment - however, it seems that if I start it in that area I cannot use the odrive commands in other namespaces - so I imagine that locahost might be used for comms? This isn’t an IPC namespace (which also exists).
If there is IPC via networking though, it won’t work if it uses localhost/127.0.0.1 as the agent is in a different space. But it would be nice to be able to communicate with it across network namspaces.
I haven’t played around much with namespaces, but your assumptions are correct. We use a simple socket connection over 127.0.0.1 for communication from the CLI to the Agent process. As you have seen, this will pose a problem when trying to use Agent across network namespaces.