Blender's code for finding files gets confused with files that are higher up in the file hierachy than itself; especially when collaborating #42588

New Issue

Bart Heijltjes · 2014-11-13T14:48:03+01:00

Bart Heijltjes commented

2014-11-13 14:48:03 +01:00

Blender Version
Broken: 2.72b

Short description of error
Blender tends to get very confused with relative paths when files are higher in the directory structure than the .blend file itself.
It sometimes gets paths that go all around the hard drive (\level1folderA\SubFolderA....\level1folderB). This used to break a lot of links in our project because the filepath would 'wander' outside of the Shared directory structure onto collaborator's personal drives.
Finally we had to switch to a shared drive letter to overcome the problem.

Here's some filepaths for textures that I found in our project (I've replaced some foldernames with ):
............\Desktop..\Google Drive<projectname>\Art\Models\Cock_Stand....\Textures\Generic\Ship_Trimmings_Decor_Silver.png............\Dropbox<company>\Models......\Google Drive<projectname>\Art\Textures\Generic\Band_steel.png <== Yes, this one first goes into a dropbox and then back out and THEN onto the google drive

Once the filepath leaves the project folder it breaks for everyone else because they don't have the same directory structure beyond that.

Exact steps for others to reproduce the error

One way I found to reliably reproduce the problem is to use the 'Make paths absolute' function on a relative path that has ".."s in it.

To be honest I have no idea how exactly the examples above happen; just that they do frequently enough to make relative paths unusable for our project.

**Blender Version** Broken: 2.72b **Short description of error** Blender tends to get very confused with relative paths when files are higher in the directory structure than the .blend file itself. It sometimes gets paths that go all around the hard drive (\level1folderA\SubFolderA\..\..\level1folderB\). This used to break a lot of links in our project because the filepath would 'wander' outside of the Shared directory structure onto collaborator's personal drives. Finally we had to switch to a shared drive letter to overcome the problem. Here's some filepaths for textures that I found in our project (I've replaced some foldernames with <replacement names>): *..\..\..\..\..\..\Desktop\..\Google Drive\<projectname>\Art\Models\Cock_Stand\..\..\Textures\Generic\Ship_Trimmings_Decor_Silver.png*..\..\..\..\..\..\Dropbox\<company>\Models\..\..\..\Google Drive\<projectname>\Art\Textures\Generic\Band_steel.png <== Yes, this one first goes into a dropbox and then back out and THEN onto the google drive Once the filepath leaves the project folder it breaks for everyone else because they don't have the same directory structure beyond that. **Exact steps for others to reproduce the error** One way I found to reliably reproduce the problem is to use the 'Make paths absolute' function on a relative path that has "\..\"s in it. ![blenderabsolutepaths.jpg](https://archive.blender.org/developer/F123630/blenderabsolutepaths.jpg) To be honest I have no idea how exactly the examples above happen; just that they do frequently enough to make relative paths unusable for our project.

Bart Heijltjes commented

2014-11-13 14:48:03 +01:00

Changed status to: 'Open'

Bart Heijltjes commented

2014-11-13 14:48:03 +01:00

Added subscriber: @WispBart

Antonis Ryakiotakis commented

2014-11-13 16:38:51 +01:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2014-11-13 16:38:51 +01:00

Might be a windows only issue, I did a test on linux with relative path of texture image 2 levels up and it was reconstructed correctly on "make paths absolute".

Bastien Montagne commented

2014-11-14 09:24:02 +01:00

Added subscribers: @MartijnBerger, @ThomasDinges, @mont29

Bastien Montagne commented

2014-11-14 09:24:02 +01:00

Martijn, Thomas, mind checking this and see if you can confirm? Made a few checks here on linux and couldn’t reproduce either…

bassam kurdali commented

2014-11-14 19:46:05 +01:00

Added subscriber: @BassamKurdali

bassam kurdali commented

2014-11-14 19:46:05 +01:00

I can perhaps add some weight to the windows theory: on our project we frequently get files back from windows users with similarly weird and broken paths, but only from windows, not other os users.
It used to be much worse some years ago, but perhaps there are still lingering bugs, or the specific user is using an older blender?

I can perhaps add some weight to the windows theory: on our project we frequently get files back from windows users with similarly weird and broken paths, but only from windows, not other os users. It used to be much worse some years ago, but perhaps there are still lingering bugs, or the specific user is using an older blender?

Campbell Barton self-assigned this 2014-11-17 11:42:16 +01:00

Sergey Sharybin commented

2014-11-18 10:42:47 +01:00

Added subscriber: @Sergey