Hi Camaleón, sorry for replying quite late, but I would like to make a few points clean before releasing squeeze. So, please, help me in understanding how tot solve the problem you reported.
My point of view is that changing a default behaviour, when you have a package already packages since long, it something I would avoid. Moreover, I believe that this default is good: you give administrator one months in order to check all archives, you give users one months in order to get back to their faxes, you avoid disk to be filled without noticing it. Il giorno sab, 19/12/2009 alle 15.37 +0100, Camaleón ha scritto: [...] > 1/ Fax archiving is not always a good idea. As received and sent faxes > are removed from the active queues, they are not longer available for > the users to review them in an easily manner. Anyway, is a task that > has to be carefully reviewed by the administrator before getting > executed. You are right here. Every FAX is archived only under two different options: first, the administrator configure the system so that every fax is archived; and second, the fax submitter ask for archiving it. > 2/ There is a second (and more severe) problem with this routine: it > deletes files that should not be deleted at all. > > For example, I maintain a big spool for faxes, documents and logs > (since 2.006) and that routine automatically deletes (just "erases" > without archiving) any unreferenced file that founds. > > That means the files are completely lost, none option to restore them > from /var/spool/hylafax/archive. This is addressed by backups. That's why people do backups: when you miss a file, you get it back from tape. Moreover, are you telling that you store non-hylafax documents under /var/spool/hylafax? I don't really understand your sentence, sorry. > 3/ That behavior forced me to disable the routine at all so it gets not > executed but I fear that any security update of hylafax-server package > just restores the script and activates it again. > > So my wish is for this script to be disabled by default because the way > is configured right now it can delete your files. no, don't worry. cronjobs are conffiles, so whenever you install a new package, if anyone changed the original shipped cronjob, debconf will ask you if you want to replace the changed file with the new shipped version. Anyway, you write that you had to *completely* disable the routine. Are you suggesting you would like a more parametric routine? What part would you live in place and what part would you disable? Bye, Giuseppe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
