Hi Giorgio,
On 11/10/18 05:49, Giorgio Garabello via Ql-Users wrote:
But i never keep in my mind to use a "public" fieds to store applicative
dependant info.
Hmm. The backup date is applicable to the file on the hard disc. It
holds information about the file on disc and not about the
Il mer 10 ott 2018, 23:34 Norman Dunbar via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:
> Hi Giorgio,
>
> but the applications can change any part of the header, especially if the
> user has DJToolkit, Turbo Toolkit, TK2 etc. So should we stop using file
> lengths, data space, file types
Hi Giorgio,
but the applications can change any part of the header, especially if the user
has DJToolkit, Turbo Toolkit, TK2 etc. So should we stop using file lengths,
data space, file types etc?
Not once has my own backup system been compimised by any application writing to
the header, nor
IMHO it's too vulnerable, anyone can change that.
It would be much safer to store it in an internal application database.
It is the concept itself that an application can directly modify file
system data that is dangerous.
Giorgio
Giorgio,
nothing dangerous here. DEC VMS, for example, does it in exactly in the same
way.
The danger you seem to see (application sets a backup date, other app uses
something different) is circumvented by supplying an old "full" backup to any
incremental one for the programs to compare. In
On 9 October 2018 at 16:44, Giorgio Garabello via Ql-Users <
ql-users@lists.q-v-d.com> wrote:
> In the header file we have the backup date field from what is not used.
> Can not be used to insert us from file creation date?
>
Wouldn't this break any backup software?
I've written HARDBAK back in
In the header file we have the backup date field from what is not used.
Can not be used to insert us from file creation date?
What do you think?
Giorgio
___
QL-Users Mailing List
