export mount points

[butonic]

In order to reconstruct the mount points during import we need to have the name of the mount point. We can either export all mount points

1. into a mounts.jsonl, or
2. as lines in the files.jsonl

the former may be cleaner, the latter may be more convenient. It is something we have considered for oc10 as well. in reva / ocis storage providers are responsible for listing mount points in a ListCollection response as references.
I'd go with the latter ... makes it easier to import them into reva. ...

how is the mount point import done when using oc10 to ex & import. In #7 I found

State of the shares not kept. Shares will be always auto-accepted during import regardless of the auto-accept checkbox

will they implicitly all be mounted to / ?

[IljaN]

There is no concept of mounts as far as data_exporter is concerned. We only tested with shares in / so not sure what will happen with nested shares.

will they implicitly all be mounted to / ?

Probably yes

1. into a mounts.jsonl, or
2. as lines in the files.jsonl

As far as I understand the mount point is an integral part of the path to be able to uniquly indentify a file in the "file-system" so I instinctively would store it inside files.jsonl, else we need to build lookup between mounts.jsonl and files.jsonl?

[butonic]

Some clarifications:

1. incoming shares can be moved to subfolders
2. incoming shares cannot bo moved into other shares
3. incoming shares cannot bo moved into other external storages (AFAICT)

In order to reconstruct where an incoming share was mounted we need to export that information. I recommend as part of the files.jsonl. it needs to reference the actual share and file ... by id or by user & path I dont care. I' use the shareid and fileid as additional entries in the files.jsonl.

references are needed, no matter if we use files.jsonl or mounts.jsonl

the only way to get around references is by attaching everything to the files.jsonl rows:

• file metadata
• share metadata
• version metadata
• tags metadata
• comments metadata

splitting this into multiple files is a lot easier, but it requires a fileid to tie it back together 🤷‍♂️