'~.' was a pun with the @ta encoding, which could cause people to get
confused about how the mapping actually worked.
I had previusly wanted the escape sequence to be a valid @ta, since I
had wanted to check that path components were (sane %ta) prior to doing
$knot conversion. However @joemfb mentioned that it was desirable to
have it not be a valid @ta so that if someone messed up the encoding in
the future, the paths would be detectably wrong.
This necessitates calling _unix_knot_to_string on unsanitized input,
which means we can no longer assume that it won't contain non-(sane %ta)
characters, which means we can no longer assert that '\\' is not in the
string on Linux.
Also added a seemingly forgotten null byte to _unix_knot_to_string.
- Don't test for '\\' in u3_unix_safe. Doing otherwise was crashing vere
when unmounting a mountpoint that had come to contain a file with '\\'
in its path. This might mean you can do bad things on Windows if other
checks fail.
- Ignore any files whose names do not pass `(sane %ta)` when scanning
directories. (This reimplements `(sane %ta)` in C. Perhaps it should
instead call `(sane %ta)`.)
- Use '~.' rather than '~' for the escape. We ignore files that end in
'~', probably for vim backup-file reasons.
- Add a _unix_string_to_knot missed in the prior conversion.
unix cannot represent the file with empty name, and it has special
mappings for '.' and '..'. as these three are all valid arvo `+knot`s,
we need to escape them if we come across them.
the method we use to escape is: if we encounter any of those three
`+knot`s, or any `+knot` starting with '~', we prepend its filename with
a '~'. and when going from filename to `+knot`, we do the reverse; i.e.
we ignore a '~' if it is the first character of a filename.
the current implementation just crashes if it encounters a `+knot`
containing '/' or '\\', neither of which are valid under the current
implementation of `@ta` (which only accepts numbers, lowercase, '-',
'~', '.', and '_'.)
it also crashes if it encounters a file containing '\\'. something else
should happen here; most likely vere should just ignore the file.
