From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Description of problem: Once there is a share available in smb.conf, s-c-samba will list it, and provides a button to select and adjust Properties. 1. adjusting the share name adjusts the share name, but also places a repeated copy of: path = /folder2 at the top of smb.conf (using the path of the share name that was modified). 2. adjusting the shared folder name, also puts a repeated copy of the folder name at the top of smb.conf, for each adjustment made. Doing a few mods in a row can leave multiple path=... settings at the top of smb.conf Version-Release number of selected component (if applicable): system-config-samba-1.2.22-0.fc3.1 How reproducible: Always Steps to Reproduce: 1. s-c-samba|add|directory=folder1 (sharename defaults to folder1) |access|everyone|OK 2. select share folder1|Properties|directory=folder2 (sharename changes to folder2). 3. select share folder2|Properties|exit 4. select share folder2|share=folder3 Actual Results: view smb.conf 1. service def: [folder1] path = /home/folder1 guest ok = yes 2. path = /home/folder2 !oops [global] ... [folder2] path = /home/folder1 !oops differs from what ui is showing guest ok = yes 3. summary screen is showing share=folder2, folder=/home/folder1 which differs to the service list you just came from. 4. path = /home/folder1 path = /home/folder2 [global] ... [folder3] path = /home/folder1 guest ok = yes Expected Results: 2. should have updated the existing path = within the share being edited, rather than placing the correct line at the top of smb.conf 3. summary screen and properties should have identical detail. 4. updated the service incorrectly, and added additional path=line at top of smb.conf. Additional info: 1. testparm doesn't complain about entries before global ! 2. properties button may force reload of smb.conf info, but this doesn't refresh the main service list from disk. 3. keeping s-c-s open like this compounds the problem, whereas if it was closed and reopened between each step, I see details as written in smb.conf 4. possibly caused by: #110804 Should be able to set share name manually fix 5. manual workaround get rid of bad lines in smb.conf 6. possible simple fix: allow view of properties, but no change of share name or folder for an existing share. 7. better fix: make it work right. 8. may be possible to
8. may be useful to note file modification time and warn user that another program edited the config file between loading and preparing to save the config; how is this situation normally handled ? (Manually removing the offending lines and fixing the service def, while s-c-s is still open is lost by s-c-s if it updates the .conf.
Oh my, this was a real bugger. To get this right I had to revamp the whole smb.conf parsing because the old stuff was real spaghetti code. Once it's available from updates/testing, please check extensively whether system-config-samba-1.2.23-0.fc3.1 fixes your problem (it should), whether it still works well as whole and report back here -- I checked all cases I could think of (adding, modifying, deleting shares) but may have missed some corner cases. For 8. please open an RFE as a separate BZ entry. Happy new year!
system-config-samba-1.2.23-1.noarch.rpm (from redhat development): http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/ Changing the folder name successfully changes the folder name in the correct part of smb.conf, and does not add the folder line at the top of smb.conf :) Delete and new work OK, along with read only, and users, ie no other oopses. erased all shares and checked OK. add new shares from scratch, also OK. Probs: 1. Doesn't remove the folder lines that the previous s-c-s added to the start of smb.conf. This would make the fix a no brainer for linux users unfamiliar with config file editing. ie fixes the fault generated by the previous version. Although, it doesn't seem to do any harm :) 2. I ran it from terminal, and get the following dep warnings, not sure how hard to change the code to eliminate these ; ( /usr/share/system-config-samba/mainWindow.py:116: DeprecationWarning: use gtk.UIManager item_fac = gtk.ItemFactory(gtk.MenuBar, "<main>", accel_group) /usr/share/system-config-samba/mainWindow.py:141: DeprecationWarning: button = self.toolbar.insert_stock('gtk-add', _("Add a samba share"), None, self.onNewButtonClicked, None, 0) /usr/share/system-config-samba/mainWindow.py:146: DeprecationWarning: self.properties_button = self.toolbar.insert_stock('gtk-properties', _("Edit the properties of the selected directory"), None, self.onPropertiesButtonClicked, None, 1) /usr/share/system-config-samba/mainWindow.py:151: DeprecationWarning: self.delete_button = self.toolbar.insert_stock('gtk-delete', _("Delete the selected directory"), None, self.onDeleteButtonClicked, None, 2) /usr/share/system-config-samba/mainWindow.py:156: DeprecationWarning: self.toolbar.insert_stock('gtk-help', _("View help"), None, self.onHelpClicked, None, 3) 3. Changing the folder value for an existing share causes the share name to change. The share name changes into the main s-c-s screen (Samba Server Configuration), but does not apply the directory name change. :( (Restarting s-c-s does fix this). 4. RFE - click (or maybe double click - depending on nautilus properties!) the share in the share list could open the share properties dialog directly. Hope this helps.
Be sure to use 1.2.24 if you want to set global preferences ;-). 1. I don't think I want to go down the path that is called "magically fixing broken config files", even if I broke it in the first place ;-). Though a nice dialog box telling the user that there is an error on line xyz in smb.conf, eventually with a button to launch a text editor would be nice, so if you want to file an RFE for it... 2. dupe of bug #134367 3. Please open a new bug for this ("Inconsistent UI when changing path on shares", just copy and paste the paragraph (I wouldn't ask that if it weren't that late here, but I don't want to lose track of it). Thanks. 4. This has been on my mind for quite a while, so you shouldn't need to open an RFE for it ;-). I think we can agree that the original bug is solved, that leaves the UI inconsistency one and perhaps a few RFEs. TIA for filing them :-P.