Relative path of archive is not preserved when copying from one repository to another.

[iiv3]

I'm using "%create-Y%.%create-m%/%id%_%source-host%" as "filename to save" that creates archives in the form of
"2023.08/202308131626266_website.com.htz"

I do use a few repositories and sometimes I (quick) save in the wrong one. When that happens I move the archive to the correct repository, using "Copy to..." from right-clicking on archive in the scrapbook list window.
However I found a number of "recent" archives were in the root of the repository "data/" directory and it turned out they are all archives that have been copied.

Aka, If I've had an archive

"temp/data/2023.08/202308131626266_website.com.htz"

and copied it to "scrapbook" it would end up in

"scrapbook/data/202308131626266_website.com.htz"

instead of

"scrapbook/data/2023.08/202308131626266_website.com.htz"

I would like to preserve the relative path ("2023.08/") when copying an archive from one repository to another.

I can manually move the archives and edit the index files, but I'd prefer not to mess with them on regular basis.

[danny0838]

I think you should get something like "scrapbook/data/202308131626266.htz" instead.

Currently the backend server does not support customized item path when generating a new item. To support it requires a major rework of the whole system, which is not likely to happen in the near future.

You can manually change the path afterwards, though, by moving the file and edit the "index" property.

[iiv3]

What do you mean by "backend server does not support customized item path when generating a new item"?

It does support customized filename, that works with paths, doesn't it?

When I make a new capture, the resulting archive is a new item that is placed in the specified (by the browser wsb extension) pathname through the backend server.

Do the same when copying.

I'm not asking to save archives in random locations across the filesystem. It's all inside the repositories (books to use the WSB term).

The "scrapbook/tree/meta.js" already contains the relative pathname as "index".

[danny0838]

No, it is the WSB browser extension rather then the backend server that supports generating a new item with customized path, which is primarily designed for a capture not saving to the backend server.

A new item will be generated when copying, importing, adding through the sidebar, or running other APIs. Supporting customized path requires a major code rework of the whole backend server system, and has to deal with a difficult problem about how to calculate a good unique ID and path for the new item.

[iiv3]

This doesn't make any sense...

When you are making a new capture... what happens if the file is not unique and already exists?
The simple solution is you return error, the WSB extension tries with new unique ID until it finds one that works (or gives up).

The thing with Unique IDentifiers is that they are supposed to be unique to begin with.

---

I do not understand why you have a separate api for "copying, importing, adding"... and what other APIs run there...

And don't get me started how useless "import" and "upload" from the sidebar are...

[danny0838]

When you are making a new capture... what happens if the file is not unique and already exists? The simple solution is you return error, the WSB extension tries with new unique ID until it finds one that works (or gives up).

The thing with Unique IDentifiers is that they are supposed to be unique to begin with.

You are not answering the question. A capture is mainly done by the browser extension, while copying an item is mainly done by the backend server side. There are lots of differences between them, and to change the latter would require a very large code rework.

[iiv3]

Let's say that we are capturing media, a single .jpg and we store it in a folder mode.

How does the extension store the capture to the backend server?
Does it open a directory, does it provide the name? How does it send the file to that directory?

When using .HTZ, is the archiving handled by the extension or the backend?
How is .HTZ archive modified when saving modifications?

[danny0838]

As previously mentioned, a capture is mainly done by the browser extension for compatibility with other non-backend capture mode. On the other hand, item management of the backend like copying, importing, etc, is mainly handled by the backend server API. Their basis are largely different.

The details about how they actually work is too far away from the topic. You can read the source code for your interest, anyway.

[iiv3]

You can implement file copying without any backend changes.

The web-extension can GET any file from any repository. And at the same time the web-extension can POST any file in any repository with any path inside it.

The backend even provides directory listing, so you can make a loop to copy folder archives.

Yes, having a dedicated function that allows the backend to locally copy a file is an improvement. And it probably would make more sense than having to implement the above "get-post piping".

---

What I do not understand is why Importing stuff requires a new API?
How is importing different than "live" capture?

---

As for the suggestion to look at the source.
Maybe you can give some hints where to look first. It's a huge project.
Maybe you have documented the API's you've used?

[danny0838]

We are not talking about the web API, but the Python API itself. Many fundamental features are based upon them, and many features make assumption of their current behavior. Changing this behavior will be a major non-trivial code rework, and may need to resurvey codes everywhere in the projects to make sure it's safe.