Bugzilla – Bug 688
Indicate when config file can't be written due to lack of disk space
Last modified: 2011-11-06 23:24:41 UTC
Related to bug 687, it would be a good idea to put some kind of obvious error message somewhere when the config file can't be written... Despite lack of disk space, I wasn't actually getting a "Can't write" message trying to write to the config file, even with d_prefs turned on. The log messages seemed to indicate that it was writing the config file just fine at every point. In this case it wasn't until I actually su'ed to the "slimserver" user and tried to edit the slimserver.conf file manually that I got a message about being out of disk space.
Further to this, it would probably be a good idea to not effectively destroy the config file in the process (once it's truncated to zero bytes, the user's configuration is lost for all intents and purposes unless they've backed it up somewhere). I suspect this may be connected to some of the complaints on the lists about mysteriously lost config files when upgrading, at least for those on a Linux platform.
Robert - how well does YAML handle this when calling DumpFile? Do we need to add any pre-checks?
Well, all it does is print() a YAML::Dump, so whatever print does when it runs out of space is what YAML will do. If we had a way to check free disk space we could do something like: my $outprefs = YAML::Dump(\%prefs); if (check_free_space() > length($outprefs) { open NUPREFS, "> $writeFile" or warn "Couldn't open prefs file for write\n"; print NUPREFS $outprefs or warn "Couldn't output prefs file\n"; close NUPREFS; } If we can't get the free space then we could just use this instead of DumpFile: open NUPREFS, "> $writeFile" or warn "Couldn't open prefs file for write\n"; print NUPREFS YAML::Dump(\%prefs) or warn "Couldn't output prefs file\n"; close NUPREFS;
This won't just not save your settings, if the disk is being filled (say by a moronic process logging that it can't write to the disk over and over again) the redirect is sufficent to cause the old file to be deleted and then nothing written. This ate my entier configuration recently which really sucked. Slimserver should really write its config files in a safer manner, for example (in pseudo code): write to config.new move config to config.old move config.new to config optionally delete config.old Then no matter what happens you have a clean copy to recover from. If move/rename isn't atomic on all platforms (I'm not sure about Windows) then "move A to B" should be replaced with: copy A to B verify that the contents of A and B are identical remove A -- Brooks
Change 6862 uses File::Slurp::write_file to make the writing of the prefs file an atomic action. Hopefully this will cure the problem of losing all your prefs when your disk is full. Still no indication, but it's a step in the right direction.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.
Unassigned bugs cannot have a priority.