Page MenuHome

bug with relative path
Closed, ResolvedPublic

Description

System Information
Win7 x64

Blender Version
Broken: 2.75RC1

Short description of error
When a .blend file is saved on for example C:\ and the image file to be loaded also on C:\ and relative path is checked, the image loading goes from 1/10th of a second to many seconds.

Exact steps for others to reproduce the error
Unpack the archive somewhere, open the .blend and load the image in folder "textures".


I just saved the default scene and the texture comes from the barcelona pavillon demo file from blender.org
Important is: .blend and image file in same logical drive but different folder. Scene must be saved (doesn't happen with a fresh start). "Relative path" has to be activated in the image loading window.

Event Timeline

mathieu menuet (bliblubli) raised the priority of this task from to 90.
mathieu menuet (bliblubli) updated the task description. (Show Details)
mathieu menuet (bliblubli) edited a custom field.
Bastien Montagne (mont29) lowered the priority of this task from 90 to 30.Jun 13 2015, 10:16 AM

Do you have any missing and/or remote 'virtual' drives on your machine? That kind of sounds like Windows trying to check content from some low speed (or missing) path… Remember we had similar issues with filebrowser's bookmarks.

@Martijn Berger (juicyfruit) maybe you can have a look here too?

@Bastien Montagne (mont29) no I don't have any virtual drives. And if I uncheck "relative path" everything is responsive again.

why is this incomplete ? Because you thought I may have some virtual drives??? Can you understand it hurts to get it many times a day after hours (yes hours) of work narrowing many bugs and then just get "incomplete" without any mentioned reason? I'm not paid nor thanked for my work so please, respect it at least. And no, I don't care if you fix it or not, I just narrowed a bug several users reported. So I'm helping in the communication process because many don't want the hassle of coming here, other don't want to report anymore and some don't know how to find a bug or don't even read your requirement. So if I'm bothering you, tell it clearly and I'll let you in peace, promised.

Bastien Montagne (mont29) raised the priority of this task from 30 to Normal.Jun 13 2015, 11:22 PM

I’d appreciate if you left susceptibility outside of bug tracking. You may report a handful of bugs (which is greatly appreciated), but we have to handle tens of them each week here - and believe me, making a good bug report does take time, but fixing a bug can take much much more.

Also, I’d expect you understand how tracker works, being an experienced reporter as you are - this one was tagged incomplete because I asked a question, you’ve answered it, so we go back to 'normal', nothing special here, happens all the time.

And Windows-specific bugs are double pain for us, since we have no active main dev using this platform (we all have to reboot or start a painfully slow VM to investigate them).

ok sorry, I guess I was a bit too tired yesterday night :(

did anyone besides original reporter manage to redo this error?

I imagine if this were a common problem, others would have reported already.

The "//" prefix was being passed to the file system read function (which should _never_ happen).
Guess relative paths were attempting to access a network share (causing the hang).

Added asserts so this mistake warns developers on all platforms and we don't make the same mistake again.

thank you for believing me without other users reporting. It's amazing how some user won't help to solve the problem they report on forums.
Your polishing work is deeply appreciated :)

@mathieu menuet (bliblubli), its fine, we _do_ believe reports, there just ends up being many issues we can't redo.