Within RAUC (an updating solution for embedded systems) we want to apply casync to the usecase of updating UBI volumes whose interface to userspace consists of char devices: to do so the only working solution today without intermediate extraction to a temporary regular file would be to spawn casync mkdev <BLOB_INDEX> and then to copy the whole contents of the attached /dev/nbdX over to the UBI volume's char device /dev/ubiY_Z. This is inefficient as the data has to be moved around by casync first and a second time by the copying mechanism. It would definitively be resource saving if casync extract <BLOB_INDEX> /dev/ubiY_Z works which is what the pull request's commit finally permits.
As casync checks the output's file descriptor for belonging to a regular file or a block device several times in the code I am uncertain if there are implicit assumptions in casync's decoder that I am not aware of and that are breaking down now (that's why I put the RFC in front of the pull request's title). So the question is if my patch is valid at all?
Although what this pull request changes is enough for our usecase it would definitely be appreciated if casync extract <BLOB_INDEX> could cope with pipes as output, too. Having that feature would allow to manually do things like
Within RAUC (an updating solution for embedded systems) we want to apply
casync
to the usecase of updating UBI volumes whose interface to userspace consists of char devices: to do so the only working solution today without intermediate extraction to a temporary regular file would be to spawncasync mkdev <BLOB_INDEX>
and then to copy the whole contents of the attached/dev/nbdX
over to the UBI volume's char device/dev/ubiY_Z
. This is inefficient as the data has to be moved around bycasync
first and a second time by the copying mechanism. It would definitively be resource saving ifcasync extract <BLOB_INDEX> /dev/ubiY_Z
works which is what the pull request's commit finally permits.As
casync
checks the output's file descriptor for belonging to a regular file or a block device several times in the code I am uncertain if there are implicit assumptions incasync's
decoder that I am not aware of and that are breaking down now (that's why I put the RFC in front of the pull request's title). So the question is if my patch is valid at all?Although what this pull request changes is enough for our usecase it would definitely be appreciated if
casync extract <BLOB_INDEX>
could cope with pipes as output, too. Having that feature would allow to manually do things likeon the commandline. It should be straight forward to extend this patch with
S_ISFIFO(…)
correspondingly.