Image database

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Image database

Baltissen, GJPAA (Ruud)

Hallo allemaal,

 

 

I want you to give the structure of my database so you can shoot at it or, better, have some suggestions.

 

Carrier:

- unique number

- CType = number: floppy, CD, DVD, stick, hard disk

- name = text

- where to find it = text

 

CType:

- unique number

- text     (floppy, CD, DVD, stick, hard disk)

 

Directory:

- unique number

- number = carrier

- path = string

 

DType:

- unique number

- text     (D64, D71, D80, D81, D82, D20, D30)

So far I never cared about TAP files and I have no idea how to read them. A "to-do" thing.

 

Floppy:

- unique number

- DType = number

- header = string

- disk ID = string

- MD5 = string

- user comment = string

 

FType:

- unique number

- text     (PRG, SEQ, etc.)

 

File:

- unique number

- FType = number

- name = string

- size = number

- MD5 = string

- comment = string

 

 

Met vriendelijke groet / With kind regards, Ruud Baltissen

 

www.Baltissen.org

 

 

 

 



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

RE: Image database

Baltissen, GJPAA (Ruud)

Having a second look: I forgot to write down the (for me obvious) links to the higher level. For example: a file is found inside a directory and therefore must be connected to this directory with the number of this directory.

 

 

Van: Baltissen, GJPAA (Ruud)
Verzonden: woensdag 10 mei 2017 08:04
Aan: [hidden email]
Onderwerp: Image database

 

Hallo allemaal,

 

 

I want you to give the structure of my database so you can shoot at it or, better, have some suggestions.

 

Carrier:

- unique number

- CType = number: floppy, CD, DVD, stick, hard disk

- name = text

- where to find it = text

 

CType:

- unique number

- text     (floppy, CD, DVD, stick, hard disk)

 

Directory:

- unique number

- number = carrier

- path = string

 

DType:

- unique number

- text     (D64, D71, D80, D81, D82, D20, D30)

So far I never cared about TAP files and I have no idea how to read them. A "to-do" thing.

 

Floppy:

- unique number

- DType = number

- header = string

- disk ID = string

- MD5 = string

- user comment = string

 

FType:

- unique number

- text     (PRG, SEQ, etc.)

 

File:

- unique number

- FType = number

- name = string

- size = number

- MD5 = string

- comment = string

 

 

Met vriendelijke groet / With kind regards, Ruud Baltissen

 

www.Baltissen.org

 

 

 

 



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

Re: Image database

Peter Bortas
In reply to this post by Baltissen, GJPAA (Ruud)
Hi Ruud,

I have no comments on your fields in general, just the hash part.

Avoid using MD5 when making new formats. Use something like SHA256 by default, but also include a way in the format to specify which hash is used to leve the door open for future upgrades. If you want to get fancy, provide a way to use several hashes, something for example Mame does where they still provide MD5 hashes but additionally have SHA.

Regards,
-- 
Peter Bortas


On Wed, May 10, 2017 at 8:04 AM, Baltissen, GJPAA (Ruud) <[hidden email]> wrote:

Hallo allemaal,

 

 

I want you to give the structure of my database so you can shoot at it or, better, have some suggestions.

 

Carrier:

- unique number

- CType = number: floppy, CD, DVD, stick, hard disk

- name = text

- where to find it = text

 

CType:

- unique number

- text     (floppy, CD, DVD, stick, hard disk)

 

Directory:

- unique number

- number = carrier

- path = string

 

DType:

- unique number

- text     (D64, D71, D80, D81, D82, D20, D30)

So far I never cared about TAP files and I have no idea how to read them. A "to-do" thing.

 

Floppy:

- unique number

- DType = number

- header = string

- disk ID = string

- MD5 = string

- user comment = string

 

FType:

- unique number

- text     (PRG, SEQ, etc.)

 

File:

- unique number

- FType = number

- name = string

- size = number

- MD5 = string

- comment = string

 

 

Met vriendelijke groet / With kind regards, Ruud Baltissen

 

www.Baltissen.org

 

 

 

 



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617

Reply | Threaded
Open this post in threaded view
|

RE: Image database

Baltissen, GJPAA (Ruud)

Hallo Peter,

 

 

> Use something like SHA256

 

First problem: never heard of it. OK, we have Wikipedia and Google of course....

Next problem: I don't have the source code of SHA256 in Pascal. If it is available in C, I could port it but....

 

The reasons I use MD5 are:

- I have the code in Pascal.

- I only use it to have a quick way to find out if two files are the same. If I find two with the same hash, I always can check them byte by byte to make sure they are the same indeed. Most files are smaller than 64 KB so that won't take much time.

 

 

Met vriendelijke groet / With kind regards, Ruud Baltissen

 

www.Baltissen.org

 

 

 



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

Re: Image database

Per Olofsson-2
On Wed, May 10, 2017, at 08:15 AM, Baltissen, GJPAA (Ruud) wrote:

Hallo Peter,

 

 

> Use something like SHA256

 

First problem: never heard of it. OK, we have Wikipedia and Google of course....

Next problem: I don't have the source code of SHA256 in Pascal. If it is available in C, I could port it but....


Hi Ruud,
  there are several Pascal libraries with SHA2 support out there, here's one that's actively maintained with a permissive license:


If you prefer implementing the algorithm yourself (it's not particularly tricky), here's a clean C implementation:


--
  Per Olofsson


Reply | Threaded
Open this post in threaded view
|

RE: Image database

Baltissen, GJPAA (Ruud)

Hallo Per,

 

 

> https://tls.mbed.org/sha-256-source-code

 

Thank you for the links.

 

But what I heard form others is that the SHA-256 algorithm is much more time consuming and I need to reserve more bytes in each record. And as said, I'm only using MD5 to have a _quick_ mean to compare two disks and files. I am not interested at all in the various security risks MD5 has because I don't use it as a security tool. So for the moment I stick to MD5.

 

 

Met vriendelijke groet / With kind regards, Ruud Baltissen

 

www.Baltissen.org

 

 

 

 



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

Re: Image database

Anders Carlsson
Ruud Baltissen wrote:

> And as said, I'm only using MD5 to have a _quick_ mean to compare two
> disks and files.

Given that MD5 is a 32 bit hash, does it mean it can number 4 billion
different floppy disks? While I assume all possible combinations of every
bit of Commodore software ever released would by far exceed 4 billion
combinations, perhaps for official disk releases it would be enough for this
purpose.

A 256 bit hash most certainly should be able to individually keep apart
every possible combination of all Commodore programs ever made, if it has up
to 10^77 combinations? Or maybe my combinatoric skills are misleading me on
this.

Best regards

Anders Carlsson




       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

RE: Image database

Baltissen, GJPAA (Ruud)
Hallo Anders,


> Given that MD5 is a 32 bit hash

No, 128 bit: https://en.wikipedia.org/wiki/MD5
The output of MD5 is presented in the form of 32 hexdigits, like: 9A6CD32..... etc. Maybe that confused you.


> does it mean it can number 4 billion different floppy disks?  While I assume all possible combinations of every bit of Commodore software ever released would by far exceed 4 billion combinations, perhaps for official disk releases it would be enough for this purpose.

As I understand the above you say that over 4.000.000.000 pieces of software are present.  IIRC I was told once the total quantity of C= software was somewhere between 5 and 10 GBytes. Doesn't match your 4 G of pieces. But assume that this number is correct, 128 bits, = 4G * 4G * 4G * 4G, should cover it easily IMHO.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org







De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
1�,j�j���a�����^q��i��ɚ�X��X��
Reply | Threaded
Open this post in threaded view
|

Re: Image database

Anders Carlsson
Ruud wrote:

>> Given that MD5 is a 32 bit hash
> No, 128 bit: https://en.wikipedia.org/wiki/MD5

Aha. Yes, I got confused by the 32 digits. That means it can have 256
billion combinations?

>> all possible combinations of every bit of Commodore software ever
>> released would by far exceed 4 billion combinations

> As I understand the above you say that over 4.000.000.000 pieces of
> software are present.

Well, over 4 billion combinations of how you can store a subset of the
programs A, B, C, D ... onto a 166 kB floppy disk. Assuming that each
program released is 1 kB large (and in practise most are much bigger!), a
figure of 10 gigabytes equals 10 million programs of 1 kB each. If you store
one program on each disk, you will thus have 10 million disks to enumerate,
which the 128 bits MD5 easily will handle.

If you pack them closely, you will thus be able to fit up to 166 such
programs on a single floppy disk, though I can't recall how many files on a
disk the directory has capacity for. If you make sure to not have any
duplicates, it will reduce your collection to 10000000/166 = 60241 disks, or
halve of that if you are using flippies.

My point of thinking here is that if duplicates may appear across different
disks and all those programs may be combined in any order, you get a very
large number. I found an online calculator that says that there are 10^864
ways of combining those 10 million programs into disk images of 166 files
each, and that is still only the case where each disk is entirely stuffed.

256 billion is 2*10^11 so in this theoretical case MD5 would not suffice. :)

Of course in practise those 10 gigabytes of software probably averages at 20
kB or so, reducing the set to 500,000 programs * 20 kB. Each disk image will
store 8 such programs with a bit of slack. It equals 9*10^40 different
floppy disk images with all combinations, still a larger number than
2*10^11.

If we set the average Commodore program/file to 33 kB, which I think is a
bit too large as there are a lot of small ROM images and other files that
won't get anywhere that size, we get 303030 programs of which we can fit 5
of those on each disk. The total number of combinations is down to 2*10^25.

If we pretend to be clueless and assume there never has been any smaller
files than 83 kB (easy thought in the 2017 world of computing), we get
120482 files of which 2 on each disk = 7*10^9 so in this case the 128-bit
hash would be able to hold all possible combinations.

Well, all this is hypothetical both when it comes to file sizes and the fact
that each existing file would appear on a disk image in combination with
every other existing file but this was along my way of thinking.

Best regards

Anders Carlsson


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Image database

silverdr-2
In reply to this post by Baltissen, GJPAA (Ruud)

> On 2017-05-10, at 14:15, Baltissen, GJPAA (Ruud) <[hidden email]> wrote:
>
> Hallo Peter,
>  
>  
> > Use something like SHA256
>  
> First problem: never heard of it. OK, we have Wikipedia and Google of course....
> Next problem: I don't have the source code of SHA256 in Pascal. If it is available in C, I could port it but....
>
> The reasons I use MD5 are:
> - I have the code in Pascal.

Ruud, one does not port things like these today. One uses libraries. I use various hashes extensively in numerous languages and I am yet to have a need to port any of the known hashing functions. I wanted to write that I "bet there are appropriate libraries for Pascal too" but others have already pointed you to some.

> But what I heard form others is that the SHA-256 algorithm is much more time consuming

It is.

> and I need to reserve more bytes in each record.

Negligible difference.

> And as said, I'm only using MD5 to have a _quick_ mean to compare two disks and files. I am not interested at all in the various security risks MD5 has because I don't use it as a security tool. So for the moment I stick to MD5.


The security vs. non-security risks differ only in the application of the function. If you use it as a security tool you get weak security. If you use it as comparison tool you get weak comparison.

>  - I only use it to have a quick way to find out if two files are the same. If I find two with the same hash, I always can check them byte by byte to make sure they are the same indeed. Most files are smaller than 64 KB so that won't take much time.

But what you just wrote basically voids your use of the hashing function. You don't want to compare byte-by-byte if you find hashes to match, the same as you don't want to do it when they don't match, do you? Why use the hash if you still want to do the cmp(), which basically means you don't trust your hash anyway, which brings us back to the original suggestion.

I had once similar dilemma and I worked this around by using two different fast (and weak by today's standards) hashing functions instead of one. I took that conflict is several orders of magnitude less likely to happen with two different functions than with one. I even put exception notifiers around those comparisons, knowing that they are practically "never" to be triggered. I find it an alternative solution for non-security related application to using resource extensive functions like bCrypt.

--
SD!


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

RE: Image database

Baltissen, GJPAA (Ruud)
In reply to this post by Anders Carlsson
Hallo Anders,


> My point of thinking here is that if duplicates may appear across different disks and all those programs may be combined in any order, you get a very large number.

I think where you misunderstood the way I want to use MD5. You can generate a MD5 hash of any set of bytes. And any two same set of bytes will generate the same hash code. In this case I use to generate a hash of every disk and every file on those disks I have. The moment I see two disks with the same hash, I can assume that they are exactly the same [*] and discard one of them (why should I keep it?). The same for individual files: the moment two files have the same hash code, it means they are a duplicate of each other and one can be discarded. Two disks with exactly the same files but in an other order will generate two different hash codes for the complete disk. But the individual files generate the same code. Using my Eyeball Mark One I will see that the disks can be considered as the same and I then can decide to discard one.
Regarding files: one can load a file and save it under an other name on the SAME disk. These, according to the eye, two different files will produce the same hash code. It is then up to you by using common sense what to do with these files.

Is it possible to run into two the same files, thus with the same hash codes, but that have no relation with each other? Yes. I once ran into two _new_ different games from the same producer and their hi-score files were the same. But in this case you can assume that the producer used the same hi-score format for both games and therefore, seen from a technical point of view, they are copies of each other. In such a specific case you just leave the situation as is.

[*] It is possible that two different files, not just different of content but even with different sizes, can generate the same hash code. That is called hash collision. A quick comparison of both items on byte level will solve the matter. And even SHA-256 has this problem. Side note: it is thus even possible that a disk and a file create the same hash code. But in this case I will simply ignore it.


> I found an online calculator that says that there are 10^864 ways of combining those 10 million programs into disk images of 166 files each, and that is still only the case where each disk is entirely stuffed.

I'm not interested in the combinations at all. Which means I'm only interested in 10.000.000 / 166 = 60240 of these disks.


> 256 billion is 2*10^11 so in this theoretical case MD5 would not suffice. :)

128 bits is somewhere in the zillion range, > 10^35.



Hallo Patryk,


> If you use it as comparison tool you get weak comparison.

What is weak in this case? It took people years to find out that there were vulnerabilities. And the most important was that you could create a file from a given MD5 hash that produced this hash. AFAIK this is not possible with SHA-256. But I don't care :)


> Why use the hash if you still want to do the cmp(), which basically means you don't trust your hash anyway

The moment the hashes are different, I know the files are different as well. But the moment the hashes are the same, there is a very very small chance the files aren't. It isn't a matter of trust, it is a matter of facts.

Using SHA-256 means I generate a hash with 256 bits. Lets create an ASCII file containing 64 hexdigits '0' (zero). It will produce an hash. Now lets create another file but change the last '0' into a '1' and calculate its hash. And we will keep creating these ASCII files until we end up with 64 'F's in a row. We should now have created 2^256 _different_ files. If the algorithm was perfect (and let's assume that), we should now have 2^256 different hash codes.
Now take one of these files and replace just one of the characters with a 'R'. We now have 2^256 + 1 different files. I don't know what hash code it will produce but I am 100% sure that we already produced that one before: hash collision!  
Does that mean it is weak?

OK. 128 bits simply means that I have a bigger chance of running into a has collision. But is it a bad chance? I don't think so :)


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org









De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
1�,j�j���a�����^q��i��ɚ�X��X��
smf
Reply | Threaded
Open this post in threaded view
|

Re: Image database

smf
On 12/05/2017 11:54, Baltissen, GJPAA (Ruud) wrote:
> The moment I see two disks with the same hash, I can assume that they
> are exactly the same [*] and discard one of them (why should I keep it?).

If you have the hashes and the files, then you can completely avoid any
risk caused by a collision by locating the possible match using a hash
and then comparing the old and new file byte by byte. At that point you
could arguably just use CRC32 for the hash.


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

RE: Image database

silverdr-2
In reply to this post by Baltissen, GJPAA (Ruud)

--
Sent from mobile device. Please have understanding.

On 12 May 2017 12:54:38 CEST, "Baltissen, GJPAA (Ruud)" <[hidden email]> wrote:

>The moment the hashes are different, I know the files are different as
>well. But the moment the hashes are the same, there is a very very
>small chance the files aren't. [...]

I think I understand now what is your use case. Your approach is OK.

       Message was sent through the cbm-hackers mailing list