File Path problem

When a file path from a network drive is used, vvvv throws an error and does not load the file. Also not further FileTextures are loaded, but the program is on pause:

just remove the file: notation… what you entered is a web convention url, not a normal file path.

The thing is that this is not what I entered manually, but how vvvv or the windows explorer links to the path via the explorer dialog. So I think, this should not happen or automatically be converted.

In this case, removing works as a solution, but we also just had cases in class todays where removing did not work succesfully, but straight went back to the “web convention url”.

Also I have another case, where the same problem occurs, and just “removing” does not work because it generates again an URL which is more complicated than “just removing” an obvious part of the string, when selecting a file from a desktop which is linked to a server location (i’m sure there a better name for it):

test3

It seems it also depends on where the VL-File is located how it generates either a normal file path, a “web convention URL” or the URL as in the last example".

I can tell that we constantly are having issues with this and therefore sometimes switch temporarly to a folder in C:\temp, which is of course not such a nice solution. I hope there’s still a way to automatically detect and set the correct file-path or force the file dialog to set a clean path.

Didn’t you have the same or at least a related problem before already?:

True, this was fixed back then, but for sure it has the same origin.

In this previous bug, after saving a patch with such a file path, it was blocked from reopening - which is not the case anymore.

so this seem to be two (possibly) distinct problems:

  1. why and under what circumstances does a path IOBox create invalid paths like shown in your first screenshot (ie. with multiple driver separators)
  2. why doesn’t the FileTexture node load the file when fed with a valid network path

ad 1) can you tell us exactly how this is set up: “a file from a desktop which is linked to a server location” so we can try to reproduce this?
ad 2) in this case, is this a specific problem of the Stride FileTexture node and would a Skia ImageReader fed with the same path work?

@joreg

  1. any smb network path. like \\localhost\mysharedfolder\myfile.txt gets this prefix.
  2. seems any node with path pin behaves like this. fileexists, filereader, filetexture, dir, you name it.

i remember that i did run in the same/similar/connected problem at one time that directory node and/or file selectors didnt show mounted network drives and there was something with elevated/non elevated file select dialogs.

as far as i remembered a registry entry edit did fix it for me - gonna look it up

Seems like @tgd has already brought in some relevant pointers.

In our setup, the windows user files (as “Desktop” or “Documents” are stored in a network location, which is pretty common in company networks I’d say). I can investigate further on this and we can have a call when back on location, which will be not before april 25th, but maybe even may 2nd. What I can say is that it happens regularly, but not always, probably depending on how you select the location in the windows explorer dialog window.

The strangest thing I observed in one case last Monday: after we had problems with network paths, we moved everything to the local drive, but then it happened even when linking to files located on C:\temp or other locations on the local hard drive. No matter if we restarted vvvv, having a plain new VL-patch, or opening existing patches, the windows dialog was always setting paths as:

Value="file:\\\C:\temp\filename.jpg"

Even if we deleted "file:\\\" in the path-IO-Box, it was automatically added again immediately. Did not have the change to make a screen recording as as we were in exams, but can see next time if it still happens on this machine.


02_Stride_scene.vl (26.1 KB)

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.

We’ve finally found the bugger causing this. Would you be so kind to test with a recent preview >= 6.0-91?

1 Like