So, I’m trying to understand versions and rather doing that back to front by looking at what I see.
As an example safe://cdn
From dog I see there have been 6 versions of what I wonder is the FilesContainer
and with cat (though this should be ls), I can scroll through versions of what I understand is the FilesContainer
eg safe cat safe://hnyynyzeu1mxk4pa61a6skyp31yzh3doq1pqcdd8n5f33hepbyaqao54u6bnc?v=4
Now, the dog barks currently as v=1:
$ safe dog safe://cdn?v=1
Native data type: PublishedSeqAppendOnlyData
Version: 6
Type tag: 1100
XOR name: 0xd1392dead371e963d6501b9902fcc8e0e935cc18ce2d9739e21a1061d886f53f
XOR-URL: safe://hnyynyzeu1mxk4pa61a6skyp31yzh3doq1pqcdd8n5f33hepbyaqao54u6bnc?v=6
Resolved using NRS Map:
PublicName: "cdn"
Container XOR-URL: safe://hnyydyz7h69nmeb6ttbz4gw3k8tpmhou4aoxpq9okah7hnemz4gha8r86qbqh?v=1
Native data type: PublishedSeqAppendOnlyData
Type tag: 1500
XOR name: 0xfbcf7c4b407d1886fa3532a3c5abe427ac41ed77e0ac73bc12177d1b98390fe7
Version: 1
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| NRS name/subname | Created | Modified | Link |
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| cdn | 2020-04-11T18:38:53Z | 2020-04-11T18:38:53Z | safe://hnyynyzeu1mxk4pa61a6skyp31yzh3doq1pqcdd8n5f33hepbyaqao54u6bnc?v=6 |
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
Previously as v=0
safe@water:~$ safe dog safe://cdn?v=0
Native data type: PublishedSeqAppendOnlyData
Version: 0
Type tag: 1100
XOR name: 0xd1392dead371e963d6501b9902fcc8e0e935cc18ce2d9739e21a1061d886f53f
XOR-URL: safe://hnyynyzeu1mxk4pa61a6skyp31yzh3doq1pqcdd8n5f33hepbyaqao54u6bnc?v=0
Resolved using NRS Map:
PublicName: "cdn"
Container XOR-URL: safe://hnyydyz7h69nmeb6ttbz4gw3k8tpmhou4aoxpq9okah7hnemz4gha8r86qbqh?v=0
Native data type: PublishedSeqAppendOnlyData
Type tag: 1500
XOR name: 0xfbcf7c4b407d1886fa3532a3c5abe427ac41ed77e0ac73bc12177d1b98390fe7
Version: 0
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| NRS name/subname | Created | Modified | Link |
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| cdn | 2020-04-09T12:58:06Z | 2020-04-09T12:58:06Z | safe://hnyynyzeu1mxk4pa61a6skyp31yzh3doq1pqcdd8n5f33hepbyaqao54u6bnc?v=0 |
+------------------+----------------------+----------------------+--------------------------------------------------------------------------+
Does this suggest that a domain name “nrs” (why do we call it acronym nrs?)
is only updated when the owner prompts that… and up to that point updates are to FileContainer… which I guess makes sense, if you are prepping the future instance of an entire site, you then choose to switch it as live/latest version of nrs.
Two questions then: 1of2: am I correct expecting that sync will update only the FilesContainer? 2of2 what is the command that updates nrs version?.. I worry that nrs add will create subdomain but does it perhaps overwrite and iterate the version for the nrs?
Confession: I made a mess of safe://cdn and managed to upload a copy of the entire dir as a subdir. It looks sorted now. See if you get the same results as me, please.
The command I used was:
willie@gagarin:~/projects/maidsafe/local_sites$ safe files sync cdn/ safe://cdn --recursive --delete --update-nrs
FilesContainer synced up (version 8): “safe://cdn”
Not quite: safe files sync command updates a FilesContainer if there have been any modifications in the set of source files (new, modified or deleted files). In addition, it will also update the NRS pointing to the FileContainer if:
the target parameter is the NRS URL instead of the FileContainer XOR URL.
the --update-nrs flag is passed to the command
safe nrs add does update the version. It has 2 exclusive modes:
either it updates the link of an existing name
or it adds a subname to an existing name (or updates its link if the subname already exists)
In the first case the name to pass is the complete existing name, in the second case the name to pass ends with an existing name (in the format subname.name). So, there can be no confusion between the 2 modes. If you worry to create a subdomain by accident, just never use a dot in the name argument.
EDIT: Also never use a slash in a NRS name or subname to avoid the confusion you came across a few days ago. Because something like safe://hello/style.hello is ambiguous:
it can mean style.hello file in container pointed to by safe://hello NRS map
it can mean hello/style subname of safe://hello NRS map
I think the NRS API should generate an error when a user creates a name or adds a subname with slashes in them.
Basically it is never assumed you want to update the NRS unless you opt in. Any files command changes to an existing FilesContainer will apply to that container only. Your NRS map points to a specific version of the FilesContainer so will never be affected unless you opt in to updating it with the command flag.
How common would the use case be when you don’t want to update the NRS-URL? Unless it’s very common I’d suggest treating both the NRS and XOR cases the same to avoid confusion, with the --no-nrs-update flag added as an option.
In my playing around I have hit this issue a couple of times, when I expected the NRS URL to point to the new version and it didn’t.
Just as a comment, note there is no other choice for this, we cannot figure out if a FilesContainer is linked from an NRS when the user provides a FilesContainer XOR-URL