Re: [Ql-Users] Proposal about the file system
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 etc? > Of course no. But i never keep in my mind to use a "public" fieds to store applicative dependant info. > > Not once has my own backup system been compimised by any application > writing to the header, nor have any of my users, since 1989/1990, ever > reported a problem. I think it should be safe. > > And speaking as a Database Administrator, what makes you think that a > separate database is any safer - anyone could change it. > There'a big difference between an intentional write ( i want to use YOUR DB,) and a casual overwrite (oh sorry, we are using the same field) don't think as DBA, thinks as a user that install a lot of sw on his system without know how these works. Of course this is only philosophy :-) sorry for my bad english > > > Cheers, > Norm. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] Proposal about the file system
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 have any of my users, since 1989/1990, ever reported a problem. I think it should be safe. And speaking as a Database Administrator, what makes you think that a separate database is any safer - anyone could change it. Cheers, Norm. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ QL-Users Mailing List
Re: [Ql-Users] Proposal about the file system
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 https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail; target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif; alt="" width="46" height="29" style="width: 46px; height: 29px;" /> Mail priva di virus. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail; target="_blank" style="color: #4453ea;">www.avast.com 2018-10-10 9:55 GMT+02:00, Tobias Fröschle via Ql-Users : > 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 case you have none, the > backup program will automatically do a full backup and initialise the time > stamps. > > Dangerous is when you use the backup timestamp for something else > > Tobias > >> Am 10.10.2018 um 00:38 schrieb Giorgio Garabello via Ql-Users >> : >> >> 2018-10-09 17:26 GMT+02:00, Jan Bredenbeek via Ql-Users >> : >>> 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 1989 which uses this backup date to >>> determine >>> if files have changed since the backup. >> :-O >> May I ask you why did you choose such a dangerous option? >> >>> And what do you mean with 'file creation date', the date when the file >>> was >>> created on the medium or when it was last updated? >> >> when the file was created >> ___ >> QL-Users Mailing List > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] Proposal about the file system
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 case you have none, the backup program will automatically do a full backup and initialise the time stamps. Dangerous is when you use the backup timestamp for something else Tobias > Am 10.10.2018 um 00:38 schrieb Giorgio Garabello via Ql-Users > : > > 2018-10-09 17:26 GMT+02:00, Jan Bredenbeek via Ql-Users > : >> 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 1989 which uses this backup date to determine >> if files have changed since the backup. > :-O > May I ask you why did you choose such a dangerous option? > >> And what do you mean with 'file creation date', the date when the file was >> created on the medium or when it was last updated? > > when the file was created > ___ > QL-Users Mailing List ___ QL-Users Mailing List
