Description: Time Machine Max Size can only be set to an integer, when a float value is a perfectly valid desired setting. Further, the documentation doesn't state that it only may be set to an integer. And, if the user sets it to a float, VFS fruit ignores the setting. Perhaps related, is that setting Time Machine Max Size presumably should be in typical decimal storage units (e.g. megabytes, gigabytes, terabytes, etc), but seems to be being evaluated to be in binary units (e.g. mebibytes, gibibytes, tebibytes, etc) Steps to Reproduce: 1) Setup a test samba share using vfs_fruit. 2) Set fruit:time machine max size = 2.2T on this share. 3) On a Mac, try to do a backup to the share created above. Note resulting Time Machine backup archive max storage. 4) Now, remove that share from your Mac. 5) On the Samba server, delete the contents of the share. 6) Change fruit:time machine max size = 2T for the share. 7) Restart the Samba server for the new max size setting to take effect. 8) On a Mac, try to do a backup to the share. Note resulting Time Machine storage limit. Expected Result - For step 3 above, you would expect the available Time Machine storage for the share to be limited to 2.2T. Instead, the test shows it is the total storage of the filesystem hosting the share. (In my case 6T.) i.e. the time machine max size setting seems to be ignored - For step 8 above, you would expect the available Time Machine storage for the share to be limited to 2T. Instead, the test result shows that the Mac sees the Time Machine storage limit as 2.2T, as though the 2 Terabytes the user intended to set the setting to, is being converted to 2.2 Tebibytes. Discussion: The unexpected result from test step 3 seems to occur because the value set for "Time Machine max size" is being converted from a char to a uint64. Even though, it's perfectly valid for a user to want to set a value like 2.5T as the Time Machine limit. Nor, does the manpage say that vfs_fruit only excepts whole numbers for the value...which would be a weird thing to do. The unexpected result from test step 8 seems to occur because decimal storage units are being converted to binary. I've tried multiple values, and every time the result is exactly what you'd expect if this conversion was occurring.