RTAPE protocol format correction and some new features for collaboration

Bikeman commented 2 months ago

Fix for interoperability with ITS DUMP (problem with status field fixed)
Added more freedom for mapping tapes to file names on the tape server remote system: The default behaviour continues to name tape files as the name of the drive to mount, passed by the remote client. The new options -R and -W allow to specify a printf-style format string (separately for READ-only and WRITE or BOTh (R/W) mounts where the client's chaosnet peer address and the drive name can be used as filename components. Examples are given in the usage help output.

The main use case could be a remote server that will prevent tapes from different client hosts to accidentally overwrite each other, but allowing remote hosts to exchange tapes in read-only mounts.

ams commented 2 months ago

I'd put the examples in the README.

How does this work from non-ITS hosts, e.g. Lisp Machines? I'm not sure there is a drive unit, @bictorv knows better...

bictorv commented 2 months ago

How does this work from non-ITS hosts, e.g. Lisp Machines? I'm not sure there is a drive unit, @bictorv knows better...

With the New Tape system, a device string can be "host:deviceUnit" (e.g. "host:mt0" or "host:rtapebackup240812") or "host:device:unit" (e.g. "host:rtape:backup-240812").

I agree about putting the examples in the README.

I'm not sure about the proposed tape naming functionality. For example,

the "peer" part is only the octal address, not the name of the host (which I think would be nicer)
you can't put all of a peer's tape files in a separate subdir (which would often be nice) if you at the same time want to prevent "/" in supplied drive names (but maybe the "/" checking should be smarter, allowing subdirs but no initial / or ".." etc - use realpath())
the part about allowing read but not write of another peer's tape files seems a bit of a hack, and I'm not sure how useful it would be? (I for one would prefer to only have to specify a tape-name-format once, for read/write/both).

And I'd propose breaking this up into one PR for the constants (great!), and one for the tape naming?

larsbrinkhoff commented 2 months ago

Thanks for the contribution! I have a bit too much on my plate right now, but I'll monitor the discussion as it unfolds.

larsbrinkhoff commented 2 months ago

Agreed about putting the examples in the README rather than the help text.

Also the first two and half of the third commits are just about no-brainers. The third commit is really two changes like @bictorv said: one for the symbols and one for the -R/W options. I would suggest to take the -R/W part out and post as a separate pull request that we can discuss at length if necessary.

Bikeman commented 2 months ago

I put the protocol fix and the code beautification in a new pull request.

Chaosnet / chaosnet-tools

RTAPE protocol format correction and some new features for collaboration #16