Hi,
we are looking for guidance how to solve "interoperability" problem with
rsync. Robert reported problem with rsync from BSD to Solaris box, where
32-bit rsync fails. He compiled 64-bit rsync and that works without
problem. After some investigation he discovered that problem is with
e.g.:
> # /usr/bin/ls -l dev/mdctl
> dev/mdctl: Value too large for defined data type
>
> # truss -t lstat /usr/bin/ls -l dev/mdctl
> lstat64("dev/mdctl", 0x08046930) Err#79 EOVERFLOW
> dev/mdctl: Value too large for defined data type
>
> lets try 64bit version of ls:
>
> # /usr/bin/amd64/ls -l dev/mdctl
> crw------- 1 root root 235, 4294902015 Sep 13 2006
dev/mdctl
After additional investigation he found that for 32-bit userspace we
limit minor to L_MAXMIN32 (because we want major+minor to fit in 32-bit
value). But only for 32-bit userspace. We allow to create bigger minors
in 64-bit userspace.
For 32-bit limit of time members in stat structure we can claim that
time outside of 32-bit range is (and will be for next 30 years) invalid
(and even ZFS has test for it), but what about minor number comming from
other systems (yes, unusual case, used only for backups)?
For people with access to Bugster, you can see some comments in CR
6248065 *ls* should be isaexec'ed (64bit on 64bit kernel, 32bit on 32bit
kernel)
And now the question - how to deal with this situation? Should we
deliver 64-bit rsync? There are no tools on Solaris to deal with such
files. Or should we discourage to bundle such tool? Should filesystems
block creating of these minors?
Best regards,
Milan
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
