bpy.ops.file.unpack_all only unpacks one file for similar filenames #100361

New Issue

Harry McKenzie · 2022-08-12T07:43:14+02:00

Harry McKenzie commented

2022-08-12 07:43:14 +02:00

System Information
Operating system: Windows 7
Graphics card: NVIDIA GeForce GTX Titan 2015

Blender Version
Broken: 3.3.0 Beta, branch: master, commit hash: bae2ce0695
Worked: never worked, tested on 2.93, 3.0, 3.1, 3.2, 3.3.0 beta

Short description of error
When you have a .blend file with packed file resources containing files with similar names (i.e. sample.png, sample.png.001, sample.png.002, sample.png.003, etc) and try to unpack these files with File > External Data > Unpack Resources or running bpy.ops.file.unpack_all() in Text Editor with any method as parameter, all files get unpacked with the same name sample.png. Currently there is no known workaround for this so you will always end up with only one file being unpacked which is the last in the list.

Exact steps for others to reproduce the error
1.) Download the attached file same-name-images.blend
2.) Unpack the packed files using File > External Data > Unpack Resources
3.) Check the Info Panel to see where blender saved the file(s)

Notice that only 1 file was unpacked. There are 2 packed files in the attached .blend file, namely sample.png and sample.png.001. The unpacked file results in a file with name sample.png but it really is the packed image sample.png.001.

same-name-images.blend

**System Information** Operating system: Windows 7 Graphics card: NVIDIA GeForce GTX Titan 2015 **Blender Version** Broken: 3.3.0 Beta, branch: master, commit hash: bae2ce0695 Worked: never worked, tested on 2.93, 3.0, 3.1, 3.2, 3.3.0 beta **Short description of error** When you have a .blend file with packed file resources containing files with similar names (i.e. *sample.png, sample.png.001, sample.png.002, sample.png.003*, etc) and try to unpack these files with *File > External Data > Unpack Resources* or running *bpy.ops.file.unpack_all() in Text Editor* with any method as parameter, all files get unpacked with the same name *sample.png*. Currently there is no known workaround for this so you will always end up with only one file being unpacked which is the last in the list. **Exact steps for others to reproduce the error** 1.) Download the attached file *same-name-images.blend* 2.) Unpack the packed files using *File > External Data > Unpack Resources* 3.) Check the *Info Panel* to see where blender saved the file(s) Notice that only 1 file was unpacked. There are 2 packed files in the attached .blend file, namely *sample.png* and *sample.png.001*. The unpacked file results in a file with name *sample.png* but it really is the packed image *sample.png.001*. [same-name-images.blend](https://archive.blender.org/developer/F13368269/same-name-images.blend)

Harry McKenzie commented

2022-08-12 07:43:14 +02:00

Added subscriber: @Harry-Kunz

blender-admin commented

2022-08-12 07:43:14 +02:00

#100462 was marked as duplicate of this issue

Harry McKenzie commented

2022-08-12 07:47:09 +02:00

A user reported this problem here https://blender.stackexchange.com/questions/271718/blender-overwites-textures-with-same-name-but-different-suffix-number-when-unpac

Philipp Oeser commented

2022-08-12 10:56:45 +02:00

Added subscribers: @mont29, @lichtwerk

Philipp Oeser commented

2022-08-12 10:56:45 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-08-12 10:56:45 +02:00

Which of the options are you using?
{F13369318 size=full}

So we have two packed files with relative paths:

sample.png with (relative) filepath //sample.png
sample.png.001 with (relative) filepath //another sample/sample.png

What I am seeing is that

If you use "current directory", then blender will write the images to a textures folder
dropping a possible subfolder ("another sample") from the relative path
leading to name collisions
only one file written because of said name collisions
If you use "original location", then this will not work on my machine (since this will still try to use /c/Users/knia/Desktop/ as a base path which does not exist on my machine

So there does not seem to be an unpacking option to actually unpack these in a relative (to the current blend file) way, which is quite surprising to me.

Note we also have https://docs.blender.org/manual/en/3.4/files/blend/packed_data.html#selective-unpacking.
And even though this is the same underlying code, the documentation and UI actually sound wrong to me

There I have
{F13369423 size=full}
Clicking on the “gift box” icon gives me (only indication is that this will be relative -- only thing to assume is this being relative to the current blend file)
{F13369431 size=full}
But it will try to use the original blends basepath (not existent on my machine)
{F13369443 size=full}

Note to myself: check WRITE_ORIGINAL / PF_WRITE_ORIGINAL.
Code might work as expected, will confirm for now though because (at least the selective-unpacking case is very misleading). @mont29 might know more.

Which of the options are you using? {[F13369318](https://archive.blender.org/developer/F13369318/image.png) size=full} So we have two packed files with relative paths: - `sample.png` with (relative) filepath `//sample.png` - `sample.png.001` with (relative) filepath `//another sample/sample.png` What I am seeing is that - [x] If you use "current directory", then blender will write the images to a `textures` folder - dropping a possible subfolder ("another sample") from the relative path - leading to name collisions - only one file written because of said name collisions - [x] If you use "original location", then this will not work on my machine (since this will still try to use `/c/Users/knia/Desktop/` as a base path which does not exist on my machine So there does not seem to be an unpacking option to actually unpack these in a relative (to the current blend file) way, which is quite surprising to me. Note we also have https://docs.blender.org/manual/en/3.4/files/blend/packed_data.html#selective-unpacking. And even though this is the same underlying code, the documentation and UI actually sound wrong to me There I have {[F13369423](https://archive.blender.org/developer/F13369423/image.png) size=full} Clicking on the “gift box” icon gives me (only indication is that this will be relative -- only thing to assume is this being relative to the current blend file) {[F13369431](https://archive.blender.org/developer/F13369431/image.png) size=full} But it will try to use the original blends basepath (not existent on my machine) {[F13369443](https://archive.blender.org/developer/F13369443/image.png) size=full} Note to myself: check `WRITE_ORIGINAL` / `PF_WRITE_ORIGINAL`. Code might work as expected, will confirm for now though because (at least the selective-unpacking case is very misleading). @mont29 might know more.

Harry McKenzie commented

2022-08-12 12:15:56 +02:00

I tried all options with .blend file in the Downloads folder because I was trying to find a workaround. These are the Info Panel outputs for each option: (there is some minor inconsistency with a debug trace of bpy.ops.node.select for only the first 2 options but nevermind that).

#Use files in current directory (create when necessary)
bpy.ops.node.select(wait_to_deselect_others=False, mouse_x=309, mouse_y=214, deselect_all=True)
bpy.ops.file.unpack_all(method='USE_LOCAL')
Saved packed file to: C:\Users\xxxx\Downloads\textures\sample.png

#Write files to current directory (overwrite existing files)
bpy.ops.node.select(wait_to_deselect_others=False, mouse_x=390, mouse_y=245, deselect_all=True)
bpy.ops.file.unpack_all(method='WRITE_LOCAL')
Saved packed file to: C:\Users\xxxx\Downloads\textures\sample.png
Saved packed file to: C:\Users\xxxx\Downloads\textures\sample.png

#Use files in original location (create when necessary)
bpy.ops.file.unpack_all(method='USE_ORIGINAL')
Saved packed file to: C:\Users\knia\Desktop\sample.png
Saved packed file to: C:\Users\knia\Desktop\another sample\sample.png

#Write files to original location (overwrite existing files)
bpy.ops.file.unpack_all(method='WRITE_ORIGINAL')
Saved packed file to: C:\Users\knia\Desktop\sample.png
Saved packed file to: C:\Users\knia\Desktop\another sample\sample.png

#disable auto-pack, keep all packed filesbpy.ops.file.unpack_all(method='KEEP')#Remove Pack
bpy.ops.file.unpack_all(method='REMOVE')

In this sample file there is another folder that serves as a quasi namespace but in the original thread with this issue all files are in the same directory. In the documentation link you have provided it mentions "A single file can be unpacked by clicking on the little “gift box” icon to the left of its file-path UI widget" but I cannot find this "gift box". Where is that? It says left of its file-path UI widge but I don't know where that is.

I tried all options with .blend file in the Downloads folder because I was trying to find a workaround. These are the Info Panel outputs for each option: (there is some minor inconsistency with a debug trace of bpy.ops.node.select for only the first 2 options but nevermind that). **#Use files in current directory (create when necessary)** bpy.ops.node.select(wait_to_deselect_others=False, mouse_x=309, mouse_y=214, deselect_all=True) bpy.ops.file.unpack_all(method='USE_LOCAL') Saved packed file to: C:\Users\xxxx\Downloads\textures\sample.png **#Write files to current directory (overwrite existing files)** bpy.ops.node.select(wait_to_deselect_others=False, mouse_x=390, mouse_y=245, deselect_all=True) bpy.ops.file.unpack_all(method='WRITE_LOCAL') Saved packed file to: C:\Users\xxxx\Downloads\textures\sample.png Saved packed file to: C:\Users\xxxx\Downloads\textures\sample.png **#Use files in original location (create when necessary)** bpy.ops.file.unpack_all(method='USE_ORIGINAL') Saved packed file to: C:\Users\knia\Desktop\sample.png Saved packed file to: C:\Users\knia\Desktop\another sample\sample.png **#Write files to original location (overwrite existing files)** bpy.ops.file.unpack_all(method='WRITE_ORIGINAL') Saved packed file to: C:\Users\knia\Desktop\sample.png Saved packed file to: C:\Users\knia\Desktop\another sample\sample.png **#disable auto-pack, keep all packed files**bpy.ops.file.unpack_all(method='KEEP')**#Remove Pack** bpy.ops.file.unpack_all(method='REMOVE') In this sample file there is another folder that serves as a quasi namespace but in the [original thread with this issue ](https://blender.stackexchange.com/questions/271718/blender-overwites-textures-with-same-name-but-different-suffix-number-when-unpac) all files are in the same directory. In the documentation link you have provided it mentions "A single file can be unpacked by clicking on the little “gift box” icon to the left of its file-path UI widget" but I cannot find this "gift box". Where is that? It says left of its file-path UI widge but I don't know where that is.

Philipp Oeser commented

2022-08-12 12:30:54 +02:00

In #100361#1403094, @Harry-Kunz wrote:
In the documentation link you have provided it mentions "A single file can be unpacked by clicking on the little “gift box” icon to the left of its file-path UI widget" but I cannot find this "gift box". Where is that? It says left of its file-path UI widge but I don't know where that is.

e.g. Image Editor > N panel >

> In #100361#1403094, @Harry-Kunz wrote: > In the documentation link you have provided it mentions "A single file can be unpacked by clicking on the little “gift box” icon to the left of its file-path UI widget" but I cannot find this "gift box". Where is that? It says left of its file-path UI widge but I don't know where that is. e.g. Image Editor > N panel > ![image.png](https://archive.blender.org/developer/F13370023/image.png)

Philipp Oeser commented

2022-08-12 12:35:34 +02:00

I do realize though that the two methods are all we have (LOCAL will just use the textures folder [stripping any possible subfolder from a relative path leading to name conflicts as mentioned above] and ORIGINAL which is then tied to the folder the image was packed from.
In the end this might be a feature request, but we could at least make this more obvious in the UI and/or documentation.

I do realize though that the two methods are all we have (`LOCAL` will just use the textures folder [stripping any possible subfolder from a relative path leading to name conflicts as mentioned above] and `ORIGINAL` which is then tied to the folder the image was packed from. In the end this might be a feature request, but we could at least make this more obvious in the UI and/or documentation.

Philipp Oeser commented

2022-08-12 13:06:15 +02:00

Regarding the name collisions: I think this can only be improved by implementing another unpacking method which respects relative paths and creates them inside the local textures folder and/or by mentioning this in the documentation.
(the current method can be useful the possible new method - always respecting relative subfolders - could be problematic in certain cases, too)

Regarding the confusion about where "original" locations are really unpacked to, we could do something like P3140 I guess.

Regarding the name collisions: I think this can only be improved by implementing another unpacking method which respects relative paths and creates them inside the local `textures` folder and/or by mentioning this in the documentation. (the current method can be useful the possible new method - always respecting relative subfolders - could be problematic in certain cases, too) Regarding the confusion about where "original" locations are really unpacked to, we could do something like [P3140](https://archive.blender.org/developer/P3140.txt) I guess.

Harry McKenzie commented

2022-08-12 18:33:13 +02:00

Sorry if I was not clear. Please note that name collisions also happen without any subfolders. The issue is that the suffix is removed when unpacking. For example in a list of images all in the same folder:

image.png.001
image.png.002
image.png.003

They all overwirte each other after unpacking and become image.png without the number suffix. Although it is unknown why the suffix was even there after the extension in the first place. Maybe an algorithm has to be implemented that moves .png to the end or just adds another .png extension

image.png.001.png
image.png.002.png
image.png.003.png

Sorry if I was not clear. Please note that name collisions also happen without any subfolders. The issue is that the suffix is removed when unpacking. For example in a list of images all in the same folder: image.png.001 image.png.002 image.png.003 They all overwirte each other after unpacking and become **image.png** without the number suffix. Although it is unknown why the suffix was even there after the extension in the first place. Maybe an algorithm has to be implemented that moves .png to the end or just adds another .png extension image.png.001.png image.png.002.png image.png.003.png

Philipp Oeser commented

2022-08-17 12:40:45 +02:00

In #100361#1403213, @Harry-Kunz wrote:
Sorry if I was not clear. Please note that name collisions also happen without any subfolders. The issue is that the suffix is removed when unpacking. For example in a list of images all in the same folder:

image.png.001
image.png.002
image.png.003

They all overwirte each other after unpacking and become image.png without the number suffix.

Are these named image.png.001, image.png.002 etc. on disk? Or is this the image datablock name in blender?
Got an example file for this scenario as well?

Although it is unknown why the suffix was even there after the extension in the first place.

What is "after the extension"?

> In #100361#1403213, @Harry-Kunz wrote: > Sorry if I was not clear. Please note that name collisions also happen without any subfolders. The issue is that the suffix is removed when unpacking. For example in a list of images all in the same folder: > > image.png.001 > image.png.002 > image.png.003 > > They all overwirte each other after unpacking and become **image.png** without the number suffix. Are these named `image.png.001`, `image.png.002` etc. **on disk**? Or is this the image datablock name in blender? Got an example file for this scenario as well? >Although it is unknown why the suffix was even there after the extension in the first place. What is "after the extension"?

Harry McKenzie commented

2022-08-17 18:29:11 +02:00

Unfortunately I don't know the specifics. I just know that the user who encountered this problem downloaded a blend file (which he couldn't attach because it was too large) with images packed in it that had these images named with a number suffix after the .png extension: image.png.XXX. so he asked how he can unpack them with a uniqie name because the result was only 1 image named image.png. The thread he asked is here https://blender.stackexchange.com/questions/271718/blender-overwites-textures-with-same-name-but-different-suffix-number-when-unpac

Unfortunately I don't know the specifics. I just know that the user who encountered this problem downloaded a blend file (which he couldn't attach because it was too large) with images packed in it that had these images named with a number suffix after the *.png* extension: *image.png.XXX*. so he asked how he can unpack them with a uniqie name because the result was only 1 image named image.png. The thread he asked is here https://blender.stackexchange.com/questions/271718/blender-overwites-textures-with-same-name-but-different-suffix-number-when-unpac ![dbdhi.png](https://archive.blender.org/developer/F13397385/dbdhi.png)

Harry McKenzie commented

2022-08-18 13:21:25 +02:00

Here is a similar problem related to blender's image naming algo that might help. https://blender.stackexchange.com/questions/272346/import-obj-model-pictures-with-the-same-name-will-only-be-imported-once . Maybe the same code change related to naming the images can resolve that issue as well. Notice the way the images have been similarly named after importing into blender with the number suffix.

Here is a similar problem related to blender's image naming algo that might help. https://blender.stackexchange.com/questions/272346/import-obj-model-pictures-with-the-same-name-will-only-be-imported-once . Maybe the same code change related to naming the images can resolve that issue as well. Notice the way the images have been similarly named after importing into blender with the number suffix. ![qKjz5.png](https://archive.blender.org/developer/F13400179/qKjz5.png)

Philipp Oeser commented

2022-09-06 13:46:22 +02:00

Added subscriber: @1029910278

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

bpy.ops.file.unpack_all only unpacks one file for similar filenames #100361