[Bf-committers] blender v275: why are pointer-keys in file no longer unique?

[Daniel Balster]

Hi,

I'm importing 3D data directly from .blend files for a few years now. Today
I found out that if a scene was saved with version 2.7.5 it is creating
non-unique block pointers:

- the .blend consists of blocks, each of them has the "old pointer" from
the last session, and data is using these pointers as keys

here's a small C code that lists all these pointers:

// works only with le 64-bit blend files on le 64-bit machines
#include <stdio.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
typedef struct { char code[4]; int size; char *pointer; int index; int
count; } block;
int main(int argc, char **argv) {
  struct stat st;
  int fd=open(argv[1],O_RDONLY);
  if (fstat(fd, &st)) return 1;
  size_t size = st.st_size;
  void *addr = mmap(0, size, PROT_READ,MAP_FILE+MAP_PRIVATE, fd, 0);
  block *b = (block*)((char*)addr + 12);
  for (;;) {
    if (b->code[0]=='E' && b->code[1]=='N' && b->code[2]=='D' &&
b->code[3]=='B') break;
    printf("%p\n",b->pointer);
    b = (block*) (((char*)b) + sizeof(block) + b->size);
  }
  return 0;
}

compile it as blenddump and use it like this:

blenddump file.blend | sort | uniq -d

and it will show you duplicate pointer keys.

This behavior started with v275, if you load any older version and save it,
it will suddenly have these non-unique keys.

The data blocks causing this are only the CustomDataLayer's

so if you have a mesh with ldata, pdata, vdata, etc the back-reference to
another block should be impossible, but it's still working for blender.
Haven't checked why it's still working, just want to put this here.

Any clues? Intended behavior? Could this cause problems?

-daniel-