Announcing: ZFS-fuse 0.7.0
#67 — Improve parsing of /etc/zfs/zfsrc
| State | Resolved |
|---|---|
| Version: | 0.6.9 |
| Area | User interface |
| Issue type | Bug |
| Severity | Medium |
| Submitted by | Seth Heeren |
| Submitted on | Jun 26, 2010 |
| Responsible | Seth Heeren |
| Target release: | 0.7.0 |
Last modified on
Jun 26, 2010
by
Seth Heeren
Parsing of zfsrc is quite broken
#61 using the default zfsrc doesn't work
#64 Parsing zfsrc results in unable to start daemon
and additional feedback on the user list http://groups.google.com/[…]/cbf0dc79db7a1fb3
Stefan wrote:
> I think Stefan is pointing out that it's important to use
> 'default_permissions,noatime' (or whatever fuse options are wanted)
> exactly as specified, and that adding any space after the comma will
> cause it to fail (somewhat surprisingly).
Use
fuse-mount-options = default_permissions, noatime
and you get some errors, misleading (not really pointing at the reason).
For me zfs-fuse does not start with this setting, I get the
usage-instructions displayed then ...
With
fuse-mount-options = default_permissions,noatime
(no space after the ",")
it starts fine.
BUT:
If I use
fuse-mount-options =default_permissions,noatime
(no leading space, none after ",")
it doesn't start up as well.
And with
fuse-mount-options =default_permissions, noatime
it starts.
Another small bug to file?
Stefan
#61 using the default zfsrc doesn't work
#64 Parsing zfsrc results in unable to start daemon
and additional feedback on the user list http://groups.google.com/[…]/cbf0dc79db7a1fb3
Stefan wrote:
> I think Stefan is pointing out that it's important to use
> 'default_permissions,noatime' (or whatever fuse options are wanted)
> exactly as specified, and that adding any space after the comma will
> cause it to fail (somewhat surprisingly).
Use
fuse-mount-options = default_permissions, noatime
and you get some errors, misleading (not really pointing at the reason).
For me zfs-fuse does not start with this setting, I get the
usage-instructions displayed then ...
With
fuse-mount-options = default_permissions,noatime
(no space after the ",")
it starts fine.
BUT:
If I use
fuse-mount-options =default_permissions,noatime
(no leading space, none after ",")
it doesn't start up as well.
And with
fuse-mount-options =default_permissions, noatime
it starts.
Another small bug to file?
Stefan
Added by
Seth Heeren
on
Jun 26, 2010 05:48 PM
Issue state:
unconfirmed → resolved
Now that I finally got some idea how the parsing was trying to work, I decided to revamp it, because, well, it needed it
It aims to be fully backwards compatible (modulo the bugs being reported). Together with prior patches, this makes the whole zfsrc/commandline experience a bit more user-friendly:
* 47f7f84 Issue #67 Improve parsing of /etc/zfs/zfsrc
* 8e5e013 more: option disable-page-cache deprecated
|\
* | 5363a60 Update zfs-fuse manpage to reflect obsoletion of disable-page-cache
* | 425a6bf deprecated DAEMON_OPTS in init scripts
* | 16e046c option disable-page-cache deprecated
* | a8eb43b fixed zfsrc parse error when no line-end on last line
Using some highlevel abstractions [sic!] as sscanf, strtok and asprintf the whole thing has been made a little bit less /erm/ accidental programming.
* we now report the command as /etc/zfs/zfsrc so users can know where the option is coming from if there is an error
* the 'option = value' case was utterly broken. sscanf has been employed to detect and handle it; this means that all the cases Stefan reported should now work
# 'option = value1, value1' will be passed as ['--option', 'value1, value2'] (not ['--option', 'value1,', 'value2'] like before)
# 'option=value', 'option =value', 'option= value', ' option=value' are now equivalent
* short options can be used
* leading dashes are only added if they're not present in zfsrc and a single dash is used for short options
* all cases still support trailing comments (although comment character is only detected at token start, like before)
* empty line or full line comments are still working like before
* we no longer risk buffer overrun due to unchecked memmove
(As a compromise, I'm still backwards compatible with specifying many options on one line, as long as it is not an 'assigment type' of option (see above). Note however that this is a quirk, no more than 10 tokens are ever parsed (so the rest is silently ignored!) and no magic dashes are prepended for subsequent options.
I honestly don't know why this was there and who'd use it...)
It aims to be fully backwards compatible (modulo the bugs being reported). Together with prior patches, this makes the whole zfsrc/commandline experience a bit more user-friendly:
* 47f7f84 Issue #67 Improve parsing of /etc/zfs/zfsrc
* 8e5e013 more: option disable-page-cache deprecated
|\
* | 5363a60 Update zfs-fuse manpage to reflect obsoletion of disable-page-cache
* | 425a6bf deprecated DAEMON_OPTS in init scripts
* | 16e046c option disable-page-cache deprecated
* | a8eb43b fixed zfsrc parse error when no line-end on last line
Using some highlevel abstractions [sic!] as sscanf, strtok and asprintf the whole thing has been made a little bit less /erm/ accidental programming.
* we now report the command as /etc/zfs/zfsrc so users can know where the option is coming from if there is an error
* the 'option = value' case was utterly broken. sscanf has been employed to detect and handle it; this means that all the cases Stefan reported should now work
# 'option = value1, value1' will be passed as ['--option', 'value1, value2'] (not ['--option', 'value1,', 'value2'] like before)
# 'option=value', 'option =value', 'option= value', ' option=value' are now equivalent
* short options can be used
* leading dashes are only added if they're not present in zfsrc and a single dash is used for short options
* all cases still support trailing comments (although comment character is only detected at token start, like before)
* empty line or full line comments are still working like before
* we no longer risk buffer overrun due to unchecked memmove
(As a compromise, I'm still backwards compatible with specifying many options on one line, as long as it is not an 'assigment type' of option (see above). Note however that this is a quirk, no more than 10 tokens are ever parsed (so the rest is silently ignored!) and no magic dashes are prepended for subsequent options.
I honestly don't know why this was there and who'd use it...)
