drive-letter folding windows to linux path mapping

[rupert thorpe]

Hello,

Some tools (eg: blender, Cygwin) will do drive-letter folding, 

where by "P:/whatever/..." on windows will map to "/P/whatever/..." on Linux out of the box.

and vice versa.

This allows us to essentially ignore the complications of the different pathing. we can just mount at the root, or have a sym link there, and it all magically works.

is it feasible to do this with gaffer?

R

  

[eric...@gmail.com]

It's something we can consider. My first thought is that it might be tricky to find all the places a conversion needs to be made, and to do so without interfering with innocent strings. I'll throw out a few questions to see how wide-ranging you'd think this should be for it to be the most useful.

Would you want to see all attributes get the conversion from "P:/" to "/P/" and from "/P/" to "P:/"? That would be needed for shader parameters as well as regular attributes. Primitive variables too?

Would there be a risk of changing strings that are not meant to be file names?

Is there value in making it a more general string replacement setup, like "C:/" to "/mnt/data/" and its reverse? That might allow easier adaptation to a wider range of environments like workstation, local farm, cloud farm.

For formats where embedded paths can be modified, like USD and its asset resolver, we'd let those take care of this? For data formats that don't have that concept, like EXR metadata, we'd want to make the conversion?

Who would you expect to be responsible for the path in expressions, the writer of the expression or the consumer of it?

- Eric

[rupert thorpe]

Hi Eric,

thanks for engaging :)

In my oversimplified view of things, it would be handled closer to the filesystem, so that when gaffer tried to read a file from disk, on a linux system "c:/" would get converted to "/c/"

This is likely ignoring the reality of paths in gaffer, where I guess texture paths are not even being read by gaffer, but rather they are just attributes that get passed on to the renderer?

Is there any flag to determine which attributes are paths and which are not? (I feel like there is) 

On Fri, Mar 27, 2026 at 9:12 PM eric...@gmail.com <eric...@gmail.com> wrote:

It's something we can consider. My first thought is that it might be tricky to find all the places a conversion needs to be made, and to do so without interfering with innocent strings. I'll throw out a few questions to see how wide-ranging you'd think this should be for it to be the most useful.

Would you want to see all attributes get the conversion from "P:/" to "/P/" and from "/P/" to "P:/"? That would be needed for shader parameters as well as regular attributes. Primitive variables too?

Would there be a risk of changing strings that are not meant to be file names?

Paths that start with "[driveletter]:\"  seem pretty safe to me, windows paths always start like this, linux paths never do. 

 

Is there value in making it a more general string replacement setup, like "C:/" to "/mnt/data/" and its reverse? That might allow easier adaptation to a wider range of environments like workstation, local farm, cloud farm.

yes - but I think there is also value in a default behavior that matches other tools (blender)

 

For formats where embedded paths can be modified, like USD and its asset resolver, we'd let those take care of this? For data formats that don't have that concept, like EXR metadata, we'd want to make the conversion?

I wouldn't expect gaffer/maya/blender/whatever to deal with this. I would only expect the dcc to handle paths that it is more directly "in charge of"

 

Who would you expect to be responsible for the path in expressions, the writer of the expression or the consumer of it?

The consumer. like in blender I can have a path built with an expression that resolves to 'z:/whatever', and blender will happily read from '/z/whatever'

I guess I am trying to push for a standardised linux <-> windows path mapping, based on trying to have an easier life, which may be an ambitious goal lol.

maybe if gaffer just did this with file reading it does directly itself, and then we can push arnold etc to follow the same convention in the future.

R 

 

- Eric

On Wednesday, March 25, 2026 at 8:22:09 AM UTC-4 pure...@gmail.com wrote:

Hello,

Some tools (eg: blender, Cygwin) will do drive-letter folding, 

where by "P:/whatever/..." on windows will map to "/P/whatever/..." on Linux out of the box.

and vice versa.

This allows us to essentially ignore the complications of the different pathing. we can just mount at the root, or have a sym link there, and it all magically works.

is it feasible to do this with gaffer?

R

  

--
You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gaffer-dev/ac193328-6d72-4cb2-8c05-832a904c158fn%40googlegroups.com.