Support for renaming files?

karlb 2018-02-11 15:04:15 UTC #1

What is the recommended way to rename files? I couldn't find a method to do this, so the obvious way to work around it would be to download the file, save it under a new name and remove the old file. However, this is less efficient and lack atomicity. Is there a better way to do it?

Similarly, I'm thinking about a saveIfNotExists method, which could help with avoiding accidental overwrites when uploading new files.

Thanks in advance,
Karl

galfert 2018-02-13 11:21:00 UTC #2

There is no direct method to rename files, so the way you proposed is also how I would do it.
In general, the filenames shouldn't be that important though, and should usually not be shown to a user. They are more of a technical implementation detail that the app itself takes care of, so the users don't need to deal with it themselves in the UI. But that always depends on the app of course.

As for the saveIfNotExists method, remoteStorage is using If-Match and If-None-Match headers for conflict detection. So as long as you have caching enabled, the library itself will use those headers to avoid accidental overwrites automatically.

When the app creates a new file or object that it hasn't cached before, remoteStorage.js will use a header If-None-Match: *. This tells the server to not create the file if one already exists for that path. In that case, the server would respond with a 412 status code instead and remoteStorage.js would emit a conflict event. See http://remotestoragejs.readthedocs.io/en/latest/js-api/base-client.html#conflict for details about that event.

karlb 2018-02-14 09:07:23 UTC #3

Thanks a lot, this is very informative!

In general, the filenames shouldn't be that important though, and should
usually not be shown to a user. They are more of a technical
implementation detail that the app itself takes care of, so the users
don't need to deal with it themselves in the UI. But that always depends
on the app of course.

I'm writing an application where the user handles sqlite databases. I thought the most straightforward way would be to use one remotestorage file for each db and use the file's filename as the name in the UI. This would also increase the likelihood that other applications can work with those files out of the box.

Instead, I could use internal filenames and save a some metadata separately. This could be either as a central json file (less files, less api calls) or as a file per database (less conflicts?). Compared to my previous approach:

Pro:
- easy atomic rename
- support for more meta data (last modified, number of tables) without loading the complete dbs

Contra:
- worse interoperability with other programs

Does this reasoning sound correct, or am I missing something? Anything else to add?

raucao 2018-02-14 09:14:39 UTC #4

All sounds correct to me. I'd add that for interoperability, we generally propose creating a data module, which contains the logic for that metadata, renaming etc., and which can be re-used by other apps/developers.

https://remotestoragejs.readthedocs.io/en/latest/data-modules.html

Data modules are in a bit of a beta state at the moment, but they do work, and it would make it easier for others to interop with that data I think.

karlb 2018-02-14 09:42:31 UTC #5

I was thinking about tools like https://inspektor.5apps.com/ , backup tools, "where is all my available space gone" applications and the like. Those would show the internal file name, now.

I'm not sure how a data module would solve that. Would we try to create one metadata-saver data module with some agreed upon fields which should be used by all applications similar to mine as well as the viewer/backup tools?
If we did that, wouldn't it be similar standardization effort to extending the remotestorage protocol with rename and metadata support?

raucao 2018-02-14 10:46:33 UTC #6

Ah ok, those would use filenames, yes.

I'd propose to just create a specific one for this use case and module/category for now. Then we can experiment and iterate on that, and if it actually makes sense to standardize later on, we can extract the standardised solution from proven, running code.