[Koha-bugs] [Bug 6094] Fixing ModAuthority problems

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Sun Jul 24 19:56:13 CEST 2011


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6094

--- Comment #8 from Janusz Kaczmarek <januszop at gmail.com> 2011-07-24 17:56:13 UTC ---
Marcel, OK, at last I could find the time to review your patch.  Basically it
works as expected, i.e. the value of dontmerge syspref is obeyed and:  

If dontmerge == 1 biblio records associated with the modified authority remain
unchanged and a /tmp/XXXX.authid file is created. Then the merge_authority.pl
script makes use of it.  Of course one have to have enough rights for
merge_authority.pl to be able to delete these files (they are owned, in a
standard case, by the user under which apache is running, www-data in my case). 

If dontmerge == 0 authotiry controlled fields are smoothly updated in biblio
records.

BUT I still strongly discourage you from using /tmp as a store place for
XXXX.auth.  It really gets cleaned upon reboot in standard Debian installation
(and in others too, I guess).  What if for some reason the system has to be
rebooted, for example after a kernel update?  The two databases--biblio and
authorities--become inconsistent than (since you loose, for ever, the
information about necessary updates) and there will be no other way to make
them consistent again than rewrite every single controlled field in every singe
biblio record according to the value of the corresponding authority heading. 
We should not do it to the unconscious people :)  

I would love to sign off the patch but I think it is really dangerous now.

How about /var/tmp ? -- it is world writeable and in Debian it is recommended
for files that should not be removed upon booting.  Wouldn't it be appropriate
for you?


PS  As to the session log -- who cares about it when the system gets
rebooted...

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.


More information about the Koha-bugs mailing list