Export wants to put all 7000 images to move to one exim/backup dir and same way to import? But is this so? Why I cannot simply transfer whole pack of detailed images and then import to import original path like it was db restore?
The MAX_FILES_IN_DIR setting in config.local.php is used with the image_id (from the database) to determine which numeric sub-directory to place an image in when it is imported.
The image shown in a product is part of the 'image pairs' structure which defines an 'image_id' (not to be confused with the images table image_id) and a 'detailed_id'. Both of these reference images in the images table and then the 'image_path' coupled with the calculated sub-directory of the image_id is used to determine the location of the file in the filesystem.
So a file named foo.jpg with a detailed_id in images_lnks (and a corresponding image_id in images table) of 8143 will be located at:
images/detailed/8/foo.jpg
when MAX_FILES_IN_DIR is set to 1000.
When an image is imported, it is first looked up to see if the path is already in the images table. If so, then that image_id is reused and the sizes are recalculated. This is so that the image pairs (images_links) do not get broken when images of the same names are imported and so that thumbnail generation can be done properly..
But yes, it does export them into one big blob and if that's 70K images, it will most likely break most systems since you'll either run out of inodes or the maximum number of directory entries will be exceeded.
I understand, but when user like me exports images I understand that if image path is to images/detailed/0/1.jpg
I want this path images/detailed/0/1.jpg to be in csv file. If there where split for 1000 in one dir why then put them all to one bin while exporting ?
PS for me it was much more painless to setup test server and upgrade store to recent then spending hours on unsuccessful import attempts, everything imports just file apart images..
But they are all imported into a common directory structure under images. There is no company differentiation within the /images directory. Only for the product related to those images. I.e. they can be company specific but that's handled in the DB, not the filesystem.
The issue is that export doesn't reflect the file system structure. It reflects the database "image_path" as it relates to some relative path that is determined at runtime. So to import all of a sites imagery, you run the real risk of exceeding the systems "max files in dir" limitation since all imported imagery is expected to be within the same import folder. You can have sub-folders that will be used to create the 'image_path', but the vast majority of product imagery is essentially a flat structure.
So if you have 25K images, you're probably going to break things. But the limit is system dependent.
Total ~7000 pictures ~1.5GB. What will happen when cart exports products. Will it break to different catalogs in exim/backup/images after each 1000 images or what?
Have 4.2.2 store, installed fresh 4.2.2 on test server, restored db, made update to 4.3.4 (4.3.5 not available for me yet). After upgrade pagination does not work neither in front end neither in back end, going to products list first then second page, getting "Error Oops, something went wrong (Internal Server Error). Please try again." Can it be due to this
Total ~7000 pictures ~1.5GB. What will happen when cart exports products. Will it break to different catalogs in exim/backup/images after each 1000 images or what?
Yes, will be splitted.
Have 4.2.2 store, installed fresh 4.2.2 on test server, restored db, made update to 4.3.4 (4.3.5 not available for me yet). After upgrade pagination does not work neither in front end neither in back end, going to products list first then second page, getting "Error Oops, something went wrong (Internal Server Error). Please try again." Can it be due to this