Been sweating this one out a bit, and have made some futile stabs at
it. Here's one thing that's hanging me up.

I've specified the option --raw-devices and that works fine, but it
appears
to me when the routines from flist are run, it checks to see if the if
the
file is a link, block, regular file, etc. Raw devices show up as
character
files, so I would think that the files would categorize as an S_ISCHR
file. So what I did was edit generator.c and receiver.c to write_int if
--raw-devices was selected and the file is S_ISCHR.

What happens is that when the file is sent it comes over as a cooked
file,
zero length, and gives an invalid file index error.

Can someone point  me in the right direction with this? I think the
piece
I'm failing to understand is what actually does the copy? I should
probably
have done more than just use write_int straight out.

Help, please?




> > Is there some technical reason block devices are not supported, or is
> > it a reasonable feature which has not been implemented yet due to lack
> > of demand?
>
> What is needed is an option equivalent to -L (which says "treat
> symlinks as regular files") but for devices.
>
> The reason what you are doing doesn't work is rsync "knows" about
> block devices, and if you are runing as root (so mknod() works) then
> it can copy device files to remote computers. The problem is that you
> want to copy the _content_ of the device file, not the device file
> itself.
>
> So just add an option --copy-devices and change the code to treat
> devices as regular files when that option is set. Probably the easiest
> way to do this is a global change of S_ISREG() to IS_REGULAR_FILE()
> and make IS_REGULAR_FILE() allow device files as regular files if
> --copy-devices has been set. (there are one or two places where
> S_ISREG() should still be used after this change, look at each case
> carefully)
>
> That should be all that's needed. Let us know how it goes!
>
> and in case you don't realise, the reason it doesn't do this by
> default is that it would be a _very_ bad thing to do in most
> cases. Imagine "rsync -avz /dev/ remote:/dev" if it copied the
> _contents_ of the devices. The results would be quite spectacular!
> Particularly cute would be the attempt to synchronise /dev/mem :)
>
--
Thanks,

-b
__________________________

Wm. Williams
Sr. Systems Administrator
Cisco Systems - RTP-IT
919-392-5724
__________________________



Reply via email to