[schooltool-dev] additional data.fs's

[Tom Hoffman]

On Fri, Dec 12, 2008 at 5:46 AM, Ignas Mikalajunas <ignas at pov.lt> wrote:
> On Fri, Dec 12, 2008 at 15:31, Tom Hoffman <tom.hoffman at gmail.com> wrote:
>> On Fri, Dec 12, 2008 at 5:27 AM, Ignas Mikalajunas <ignas at pov.lt> wrote:
>>> On Fri, Dec 12, 2008 at 00:39,  <jason.straw at gmail.com> wrote:
>>>> Can I suggest that we name those by evolution number/date?  otherwise the numbers have no meaning.
>>>>
>>>
>>> At the moment backup is kind of hacky, as we are using the log
>>> roration script, so if you know how to write a reliable backup script
>>> that also manages to find out the evolution number (we only have sh in
>>> postinst script) or at least format a date nicely, and gzip the backup
>>> - I'd gladly accept a patch. Just apt-get source schooltool-common and
>>> look for the postinst script template if you want to see how
>>> not-nicely it is being performed now...
>>
>> Does it automatically gzip the second most recent backup or something?
>>  I'm just not sure about the pattern (I need to explain this in the
>> docs).
>>
>> --Tom
>>
>
> At the moment the workflow is this:
>
> If you have Data.fs, Data.fs.0, Data.fs.1.gz
>
> Rename Data.fs.1.gz to Data.fs.2.gz, Gzip Data.fs.0 as Data.fs.1.gz,
> move Data.fs to Data.fs.0, copy Data.fs.0 to Data.fs
>
> Which is broken in one respect: if something happens - you run out of
> space, hit Ctrl-C, kill apt in some place, you end up with your
> Data.fs moved to Data.fs.0 and no Data.fs at all (so school tool
> startup would create an empty Data.fs thus breaking the application as
> far as users are concerned)
>
> OTOH - maybe we don't want users to mess with unbacked up Data.fs, I
> mean - maybe running an evolution script without backup is worse than
> failing to start up properly if backups failed...

Yes, not having backup is worse.  This will do for now.

--Tom