Version: 1.7.1 (using Devel) OS: Linux Installed from: Compiled sources I am running kdesvn-build on a system where my home directory resides on an AFS filesystem. I forgot that my authentication had lapsed, and got the following when I tried to start a build: $ ./kdesvn-build Unable to open configuration file! We looked for: ./kdesvn-buildrc /afs/example.com/user/daniel/.kdesvn-buildrc kdesvn-build will continue using a default set of options. These options may not apply to you, so feel free to visit the kdesvn-build homepage http://kdesvn-build.kde.org/ and access the kdesvn-build documentation. Also the latest release package will have a sample configuration file that you can edit to your liking. print() on closed filehandle LOCKFILE at ./kdesvn-build line 3931. Script started processing at Sun Oct 12 22:39:28 2008 Encountered an error in the execution of the script. The error reported was fileparse(): need a valid pathname at ./kdesvn-build line 3342 Please submit a bug against kdesvn-build on http://bugs.kde.org/ Unable to create log directory /afs/example.com/user/daniel/kdesvn/log/2008-10-12-01 fileparse(): need a valid pathname at ./kdesvn-build line 3309 When you're not authenticated, an AFS home directory is typically unreadable (and, of course, unwritable). This obviously breaks a lot of assumptions, and the script could probably avoid a lot of the above hand-wringing (and the invitation to report a bug) if it just briefly checked that the home directory is readable/writable before proceeding.
SVN commit 904713 by mpyne: Don't blindly assume that the lock file could be opened if it didn't already exist. CCBUG:172696 M +10 -3 kdesvn-build WebSVN link: http://websvn.kde.org/?view=rev&revision=904713
I've fixed the error message about writing to a closed lock file but I don't really think there's too much more to improve in the unlikely case of a unwritable home directory. Or in other words I prefer to avoid running through a pre-run checklist of assumptions to confirm true, especially since they may change in the middle of program run anyways. In this case an exception was correctly thrown (the unwieldy message you see is the exception handler) which I think is good enough for this case. Perhaps it's not necessary to suggest reporting a bug at first shot though. :)