files get
I think I reproduced your first issue.
Upload the test data directory from the safe_network
repo:
cargo run --bin safe --release -- files put resources/testdata
FilesContainer created at: "safe://hyryyry1cwbf6ujer1sj9br4gf6681k5qw471zaqy4ngpiazcqzcu9z88oynra?v=hf1yhh3bpw7ohw5dtw9zyaw48x4sabnqgkea8mrnqiiwds9cotihy"
+---+-------------------------------------------+--------------------------------------------------------------------+
| + | resources/testdata/.hidden.txt | safe://hy8oycymskorc9j35jtc7n5qrcft85m31j1qwyop3wgokokzfw71mzga3de |
|---+-------------------------------------------+--------------------------------------------------------------------|
| + | resources/testdata/another.md | safe://hy8oyeypg8tphr18ukfeatfkw7p1zoxcw1wa19enckue138ugj5omnbcr5h |
|---+-------------------------------------------+--------------------------------------------------------------------|
| + | resources/testdata/large_markdown_file.md | safe://hy8oyeyxnyrf9jfa8817bjc5xwbhh78yqg7qqstaowcx38ij6s1wkmfqajc |
|---+-------------------------------------------+--------------------------------------------------------------------|
| + | resources/testdata/noextension | safe://hyryyyym8qq7xqhyqhm7ar9wedde6br5wcro5whnh3fjqoeoiq384y1gofr |
|---+-------------------------------------------+--------------------------------------------------------------------|
| + | resources/testdata/test.md | safe://hy8oyeypfsyugk8y1dygyxasc3cfmxu6zk8s66jyq6x6ndo1ncu7gy5yjeh |
+---+-------------------------------------------+--------------------------------------------------------------------+
If I try to use files get
to retrieve one of the files directly:
Error:
0: You can target files only by providing a FilesContainer with the file's path
Location:
sn_cli/src/subcommands/files_get.rs:338
Intuitively, this behaviour seems wrong to me. Even though files get
is more geared toward working with containers, I would expect to be able to use the command with a direct file reference.
I suspect the reason for this is because of the distinction between immutable and mutable data, but I’ll need to verify that.
I don’t think the solution is to change the behaviour of cat
. The safe cat
command is supposed to be analogous to the unix cat
command, which prints the contents of a file, so it doesn’t seem right to apply arguments to that relating to files.
I’ll look into changing the behaviour of files get
to support retrieving a file.
nrs add
If you add a subname to an NRS topname, it needs to link to something, so it makes sense that you would be required to provide a link. I actually feel here that it may be worth changing this command to make the link
argument mandatory, because if you don’t supply it optionally, it’s going to prompt you for it anyway. I don’t really see much advantage in pasting the link with the original command as opposed to pasting it after you’ve been asked for input.
Can you let me know please, what was your intuition here? Why is it surprising to you that you would have to supply a link?
files sync
There is already a --recursive
argument on the files sync
command:
Sync files to the SAFE Network
USAGE:
safe files sync [OPTIONS] <LOCATION> [TARGET]
ARGS:
<LOCATION>
The source location
<TARGET>
The target FilesContainer to sync up source files with, optionally including the
destination path (default is '/')
OPTIONS:
--config-dir-path <CONFIG_DIR_PATH>
Set the location for the config directory.
Defaults to $HOME/.safe on Linux/macOS or %USERPROFILE%\.safe on Windows
[env: SAFE_CONFIG_DIR_PATH=]
-d, --delete
Delete files found at the target FilesContainer that are not in the source location.
This is only allowed when --recursive is passed as well
-h, --help
Print help information
--json
Use JSON as output serialisation format (alias of '--output json')
-l, --follow-links
Follow symlinks
-n, --dry-run
Perform a dry run of the command. No data will be written
-o, --output <OUTPUT_FMT>
Output data serialisation: [json, jsoncompact, yaml]
-r, --recursive
Recursively sync folders and files found in the source location
-u, --update-nrs
Automatically update the NRS name to link to the new version of the FilesContainer. This
is only allowed if an NRS URL was provided, and if the NRS name is currently linked to a
specific version of the FilesContainer
--xorurl <XORURL_BASE>
Base encoding for XOR-URLs. Currently supported: base32z (default), base32 and base64
nrs register
I think there is confusion coming from the word “map” here. This is referring to an NRS map, not a “datamap”.
The NRS map contains the information about the registered top name. If you do a safe cat
on the container for the NRS map, you will see something like this:
NRS Map Container at safe://hyryygyzm4jqxhbakskbnkbjuwey68drdr1qwtgt568rx1hcmiitsu7c31on7a
Listing NRS map contents:
another.testdata: safe://hy8oyeypg8tphr18ukfeatfkw7p1zoxcw1wa19enckue138ugj5omnbcr5h
So for the registered top name, it will list all the subnames and what they point to.
We don’t actually have a “datamap” type in the network at the moment. Not that I’m aware of anyway.
We should probably just make it completely clear that we’re referring to an “NRS map” here, rather than just a “map”. I’ll get that changed.
Regarding the version, it’s not simply an integer that gets incremented. Rather, it’s the hash of the content for the entry at that point in time. Using integers is too simplistic for dealing with scenarios where there are concurrent updates to the same container.
I’m not actually sure how to get all the versions of a container. I’ll need to look into that and get back to you.
API Usage
Finally, regarding the API, can you be a little more specific about what you’re trying to do? We may be able to point you in the right direction.