Houdini: folderPath letter case

[MustafaJafar]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior:

Case changed.. In this screenshot the publisher expects the folderPath to be /Assets/Character/roboangry
However, when I create new instances, they are created with the correct folderPath.

Another Example: my actual file path (existed sometime before the latest refactoring )
\\storage\work\ayon_projects\Robo\Assets\Character\BigRobo\work\cfx
while ayon launcher recognizes it as
\\storage\work\ayon_projects\Robo\Assets\Character\bigrobo\work\cfx

Expected Behavior:

I have no suggestions.

Version

AYON server 1.0.4+202402231406
Launcher 1.0.3-dev.1
Ayon Core 0.3.0-dev.1

Also,
AYON server 1.0.4+202402231406
Launcher 1.0.0-rc.2
OpenPype 3.18.6-nightly.1

What platform you are running on?

Windows

Steps To Reproduce:

1. Open a little old workfiles before letter case to change (I'm not sure when that starts to occur but my file was created 2 month ago.)
2. Open Publisher

Are there any labels you wish to add?

• I have added the relevant labels to the bug report.

Relevant log output:

No response

Additional context:

I doubt this could be happening because I'm using the same project with openpype addon.
I tested it with OP addon and I faced the same problem. Could it be on ayon server side ?

Also, I'm not sure if this problem happens because I'm constantly testing new PRs and updating my ayon-core clone.

[cuID:AY-3849]

[BigRoy]

I think this might hint actually at a bug fix having had happened at the time, instead of there being a bug now.

So - now, it only works if it matches the case of the actual folder entity you have created it in the ayon database, yes? If so, then that works as expected. It just means that for whatever reason you have old existing scenes that had the folder paths set in an invalid way - and that after a bugfix, that invalid way is (correctly) not supported anymore.

If currently in the latest state your paths are NOT matching what the database states for the assets - then yes, there is a current bug.

Could you show this folder path in the AYON server frontend? Like what casing is the actual database entity? Does it have a 'label' authored (shouldn't influence things, but it might)?

[MustafaJafar]

It was an asset synced from kitsu.

It just means that for whatever reason you have old existing scenes that had the folder paths set in an invalid way - and that after a bugfix, that invalid way is (correctly) not supported anymore.

I think this is my case. does this mean that this issue is not an issue but rather a misunderstood ?

[BigRoy]

Interesting, this sounds like something that might be best left to someone more knowledgeable than me. But that screenshot showing both lowercased in the path and what looks to be the 'name' of the asset being camelcase - does hint to me that there must be an issue or bug somewhere.

[MustafaJafar]

your comment reminds me with community post:

https://community.ynput.io/t/naming-consistency-when-adding-folders/1169

[BigRoy]

I wonder if something somewhere is mistakenly taking the label of the folder instead of the name.

Just to confirm in this screenshot above the RoboAngry with uppercase is the label, yes?

[MustafaJafar]

Just to confirm in this screenshot above the RoboAngry with uppercase is the label, yes?

Yes.

[BigRoy]

Just to confirm in this screenshot above the RoboAngry with uppercase is the label, yes?

Yes.

In that case I'd assume the folder path in the publisher should never have been the label in the first place. (or at least not the path that got persisted with the scene)

[BigRoy]

So did this end up actually being an issue? Or some odd legacy case that just happened to be broken?

Any easy way to still reproduce this today? (Maybe you have a 'legacy' scene to share?)

[antirotor]

I don't think this is Houdini specific issue - it is more question of case sensitivity in AYON itself - you can have assets Foo and foo at the same hierarchy and the effect would be that on windows, you'll get their directories merged but on linux/mac, they will be separated. I'll close this issue now, but we should definitely document and decide if this is fine (imho having it as it is now has superlarge potential for mass confusion)