swat rewrites fields incorrectly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
samba |
Won't Fix
|
Medium
|
|||
samba (Ubuntu) |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
When SWAT re-parses the config file after making changes, it parses and displays
some of the fields incorrectly. This has a nasty side-effect: if you change a
different field, and then click "Commit" again, the broken, incorrectly parsed
values get committed to the smb.conf file, potentially breaking your Samba
configuration.
Here are the fields I've found with problems:
All mode and mask fields assume that the field will be in the format 0###. If
you want directories to be created with the sguid bit, for example, and enter in
2777, it will commit this value to the conf file and then read it back in as
02777, which breaks Samba's interpretation of that config entry.
All entry fields (or, at the very least, admin users, read list, and write list)
misinterpret user and group names with spaces in them. You should be able to put
in entries like '@group name', and indeed, SWAT will translate it to that format
if you put in something like @"group name", but when SWAT reads these back in,
it translates them to: '@group, name'.
There's probably others, but these are the ones I run into most frequently.
Changed in samba: | |
status: | Unknown → Confirmed |
Changed in samba: | |
importance: | Unknown → Medium |
Changed in samba: | |
status: | Confirmed → Won't Fix |
This looks like it should go upstream