smbmount mount_data format/kernel independence

David Collier-Brown David.Collier-Brown at
Tue Aug 8 12:45:44 GMT 2000

Urban Widmark wrote:
> A different, possibly better, idea would be to replace the current binary
> format with an ascii format. This creates a similar relationship between
> smbfs and smbmount as the one between vfat and mount, ext2 and mount, ...
> The mount program parses the options and filters out the ones intended for
> it (username, password, workgroup, ...) the rest is sent to smbfs and
> parsed there. The command:
>     mount -t smbfs -o username=foo,win95,soft,intr,case=sensitive //x/y /z
> ends up sending as "mount_data" the string:
>     version=7,win95,soft,intr,case=sensitive
> This makes smbmount capable of handling (almost) any changes to the
> flags/options passed since it does not need to understand (all of) them.
> Not unlike some of the arguments for making smbmount use mount-style
> syntax, it allows autofs to ignore what flags smbfs is using.

	This is a good approach: let's see if it meets the
	criteria for infinitely malleable...
	1) there is a distinguished null value
		yes, you can just leave out booleans, and
		say "case=,' for an empty value.
	2) obsolete options can be ignored
	3) new options can be added asynchronoulsy
	4) new, as yet unsupported options can be ignored
	5) serious incompatability can be signalled
		yes, version= will do the job.

	I'd go for it!

David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | //
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at

More information about the samba-technical mailing list