I’m trying the new DEITS feature which rolled out in 4.6.0.
I’ve created two strapi apps locally, app1 and app2, which contains the exact same content-types.
(A single type named “Test” with a single “text” field).
I’m using SQLite.
I created two instance of this content-type in app1.
Then exported the data successfully using: npm run strapi export -- --file test --no-encrypt
I tried to import the archive to app2 using the following command: npm run strapi import -- -f test.tar.gz
I assumed that the content-types were not the same between my two strapi instances. As source and target schemas must match, I also exported the data of app2 in order to compare the two “schemas_00001.jsonl” files to see if there is any differences between the two schemas, but the two files are identical.
I’m experiencing a similar issue. I get the same initial error message, but then for each entity I get a different error message:
- admin::permission:
- exists in destination schema but not in source schema
- admin::user:
- exists in destination schema but not in source schema
- admin::role:
- exists in destination schema but not in source schema
- admin::api-token:
- exists in destination schema but not in source schema
- admin::api-token-permission:
- exists in destination schema but not in source schema
- plugin::upload.file:
- exists in destination schema but not in source schema
...
I have even tried importing in the same strapi app from which I have exported and it failed on all entities.
Here’s the archive with my project code:
Included in the archive:
backup/backup_test.tar.gz - the backup file from which I tried to import
import_error_log_1676583740176.log - the error log of the failed import
Steps to reproduce:
Unpack the archive on a windows machine (I haven’t tried it on Linux)
fixed: Fatal error on import: Invalid schema changes detected during integrity checks
I have solved by editing a file in node_modules\@strapi\data-transfer\lib\file\providers\source\index.js
on Line 144: const parts = path_1.default.relative('.', filePath).split(\\');
this problem was arising on windows because :
On Windows, file paths typically use backslashes as the path separator, whereas on Unix-based systems (such as macOS and Linux), file paths typically use forward slashes.
so filePath is schema/filename.jsonl in Line 144 split method search for / but something like schema\filename.jsonl is returned by path_1.default.relative() so filter never returns true, now it is splitting by \ and parts = [‘schema’,‘filename.jsonl’];
I have created a pull requested in which issue is [fixed]
Thanks for the fix and looking into it let me get somone from strapi to look into this and get this pr merged and hopfully pushed as as soon as posible.
I can confirm for me the fix suggested by @Priyanshu_Singh worked.
I changed to:
const parts = path_1.default.relative('.', filePath).split(path_1.default.sep);
and just to be sure, at another part in the same file, line 99:
const parts = filePath.split(path_1.default.sep);
@Priyanshu_Singh, you might want to add the TS equivalent of this too in your pull request.
In general, whenever path operations are made path.sep should be used. A quick code search suggests there might be other places in the code where the same should be fixed.
I have the same issue, but in the linux, when I do an export from windows machine, I can not import the data in the linux machine, have you any solution?
Correction, the fix suggested by @Priyanshu_Singh works partially. When I apply it, I can export the data on windows machine, but cannot import it on a linux machine. Seems this is a more complex issue o fix. For now, I’ve circumvented it by doing the export on linux via docker.
