Re: [Ql-Users] Proposal about the file system
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 application. On various other file systems out in the wild, a similar thing exists - even on MSDOS there's an "archive" bit to tell some backup program that the file needs backing up. (If I remember that correctly!) 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. True, but that same user could decide to delete the database/file/whatever that holds details of the backups. Using the file's own backup date keeps the data (meta data) as close as possible to the file it applies to. That is the ideal situation. To my mind anyway. Any backup program is interesting in two pieces of data about a file, the last time it was modified and the last time it was backed up. Once you have those, you have the ability to determine if the file needs to be backed up. Without those data, the only valid backup is to completely backup everything on the hard disc. If any other backup application decides to write it's date to the backup date, then no harm done. I agree that any other application could overwrite my backup date, for example, but it could equally overwrite the file type - preventing me from EXEC'ing the file, or change the data space value resulting in the file failing to EXEC or worse, random stack based failures. So, any of the fields in the file header can be overwritten by anyone, it's the nature of the beast from 1985 I'm afraid. Of course this is only philosophy :-) :o) sorry for my bad english Never apologise for bad English, your English is perfectly understandable. My Italian is limited to please, thank you, have a good day/evening, happy birthday/Christmas, "two lemon ice creams please" and "two large glasses of white wine please". And my (late) step father was from San Remo too! Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 ___ QL-Users Mailing List
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
Re: [Ql-Users] Proposal about the file system
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. 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? In Windows (and probably Unix too), when you copy a file the creation date on the copy will be set to the date it was copied but the update date will be the same as the original (at least when using cp -p on Unix). Thus when you copy a file which was last changed 20 years ago, the update date on the copy will be 20 years behind the creation date! It's a pity that many copy utilities (like TK2's WCOPY and IIRC QPAC2's File utility) don't preserve the update date when copying files. Many of my source files I lastly touched more than 30 years ago got their time stamp smashed to somewhere in the new millennium :-(. (Yes I know you need V2 drivers to avoid this, but these have also been around since 1990 or so). Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
[Ql-Users] Proposal about the file system
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
