Re: bin/56631: rdump fails to back up to remote file

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/56631; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/56631: rdump fails to back up to remote file
Date: Sat, 22 Jan 2022 21:56:02 +0700

     Date:        Sat, 22 Jan 2022 09:25:02 +0000 (UTC)
     From:        mlelstv%serpens.de@localhost (Michael van Elst)
     Message-ID:  <20220122092502.13A9C1A923B%mollari.NetBSD.org@localhost>
 
 
   |  RMT protocol might need some abstraction to the mode argument to
   |  be portable.
   |  
   |  rdump needs an option to specify the mode, best some abstracted way,
   |  maybe also to distinguish between tapes and files.
   |  
   |  /etc/rmt might need to distinguish between files and devices, also
   |  to filter the mode. It could also try to emulate tape operations
   |  on and with files.
 
 rmt should remain for remote tape access.  That is what it is
 designed for, as tapes are (were) special, capacity generally
 quite limited, so needing rewinding and swapping in the middle
 of output ... the same could be said of old removable other
 media (floppies...) but tapes were more special in that it was
 often difficult to detect pending media exhaustion.
 
 dump needs to deal with all of that, hence the remote tape stuff
 which allows dump to manage changing the "tape" when it calculates
 that the time for that has arrived.
 
 For writing to remote files one should simply have dump
 write to stdout, then pipe that to netcat (or whatever you
 like for this purpose) rather than attempting to mangle
 the rmt protocol to become a general remote file access
 protocol.
 
 This PR should be closed.  There is nothing to fix here.