Only noticed today but when having an image file sourced by Texture VOP or VEX's colormap() the image file gets locked and cannot be written, i.e. edited in another software and then updated in Houdini, instead one gets a writing fail warning. Only when Houdini is closed can the image file be written to.


The only workaround I found was to use a COP network File COP to read the file and op:pathtocop as image source. Although this solution is not optimal especially if inside an asset used by lets say Unreal Engine, because then one has to script the File COP "Reload" button pressing.

Is there anything going wrong on my end or this is known/expected behavior?

Cheers
prb

PS: Scene attached. Place the image.png in $HOME/ and try to edit and save it with the scene open in Houdini. If only the green network box is present when the scene is opened the file can still be saved.

Hi, so I quickly tested this

opened the file
added image.tif (not png, updated node to tif)
deleted the green box and contents
saved the file
opened the file
edited the image with krita
reloaded the image

No issue.
Debian 11 XFCE
Houdini 19.5.403

SWest
Debian 11 XFCE
Houdini 19.5.403

locking files is a windows thing

SWest
Hi, so I quickly tested this

opened the file
added image.tif (not png, updated node to tif)
deleted the green box and contents
saved the file
opened the file
edited the image with krita
reloaded the image

No issue.
Debian 11 XFCE
Houdini 19.5.403

Thank you for taking the time and confirming it does not happen on Linux!

jsmack

SWest
Debian 11 XFCE
Houdini 19.5.403

locking files is a windows thing

Any other resources thill will happen? Anything that is "streamed"?

Ty for letting me know!

probiner

SWest
Hi, so I quickly tested this

opened the file
added image.tif (not png, updated node to tif)
deleted the green box and contents
saved the file
opened the file
edited the image with krita
reloaded the image

No issue.
Debian 11 XFCE
Houdini 19.5.403

Thank you for taking the time and confirming it does not happen on Linux!

jsmack

SWest
Debian 11 XFCE
Houdini 19.5.403

locking files is a windows thing

Any other resources thill will happen? Anything that is "streamed"?

Ty for letting me know!

Yes, alembic, usd, anything streamed.

It seems to be a Windows "feature", and has nothing to do with Houdini. However, your example suggest that there can be a difference here depending on what nodes are used. Unfortunately I've got not time at the moment to investigate this further.

To reduce the risks of "hacking", crashes and unexpected results it is safest to have files checked as "read only". After reading a "How do I turn off READ ONLY permanently???" [answers.microsoft.com] thread it seems that is it somewhat a "default" policy from MS. For example, what would happen if one app try to read a file that is only partially saved by another? I have my own generic experience confirming this as well.

However, as a content creator, it becomes an issue. My guess is that there should be an official method or at least a hackish way to get around this. Since I'm not using Windows at the moment (almost not at all) I do not want to investigate this however.

My guess is that this will be related to some generic filesystem or user policy settings. If you can not accept the issue, or find a fix with Windows, maybe you could try using a Linux based compatible file server for your network. The folder and file permissions settings are a bit different with Linux. I'm not sure if (a Linux based) SMB file server will allow Windows to mess it up, but I'd start with that first, then maybe try NFS if supported by your Workstation OS. However, a file server will likely not be as fast for reading and writing as local storage can be (it can quickly become a bottle neck).

jsmack
Yes, alembic, usd, anything streamed.

Thanks, dont't recall ever facing this. All those blissful years using Houdini on Linux.

SWest
However, as a content creator, it becomes an issue. My guess is that there should be an official method or at least a hackish way to get around this. Since I'm not using Windows at the moment (almost not at all) I do not want to investigate this however.

Thank you for all the feedback!

probiner
Thanks, dont't recall ever facing this. All those blissful years using Houdini on Linux.

On linux you get to crash instead.

Maybe a "solution" to this is the following. When using (source) files that should be updated over time it can be meaningful to use either folder versions or file versions. For example, when needed, I would append _v01.tif and simply increment this number. With a script it should be quite simple to filter out all file nodes and update them all to the latest available version. This way, it is possible to render out a sequence while already refining source files for the next using the same (local) storage.

If you think it is a waste of storage space it is also possible to make a script that would delete all older versions.

The key here is to decide what suffix to use because a script would search for it.

Edit: If desired, it is also possible to do the same for only the currently selected file node. Alternatively, maybe it is possible to use Python to simply make the file writable with a single click of a button. However, this would require that this permission is granted by the OS. If you can do it manually it is probably possible to automate it.

jsmack

probiner
Thanks, dont't recall ever facing this. All those blissful years using Houdini on Linux.

On linux you get to crash instead.

No crash here, just not updating, so it's probably using a temp copy in Houdini? (vid attached)

SWest
Maybe a "solution" to this is the following. When using (source) files that should be updated over time it can be meaningful to use either folder versions or file versions.

Well the workflow being aimed at here is to update the source files and wanting them to refresh on the main app, for instant feedback, say out of substance or with HDAs in Unreal Engine. So there was some immediacy in mind, like the one you have with changing the code in an Attribute Wrangle and seeing the results in the viewport. I'll check playing with permissions, thanks.

Cheers

probiner
just not updating, so it's probably using a temp copy in Houdini

I would guess that the "temp copy" is actually the image as stored in memory (RAM or VRAM).

If you start a render my guess is that it will reload the file and you should see the update.

Since the texture is used by the graphics card it is risky to "reload" a file automatically or "stream" it. Probably for this cause there is a "Reload Texture" button or equivalent.

However, since it is not the actual file being displayed but a buffer from memory (or possibly on disk somewhere) it seems somewhat unnecessary for Windows to lock the file. Maybe it should simply disable read only as soon at it has been read.

One guess, is that this could actually be a feature request to SideFX. If I'm not being wrong I think they develop for Linux first, then port it to OSX and Windows, but I'm not sure at all. If so, maybe disabling "read only" after the file was read simply got forgotten by the devs. I'm just speculating here.

Attribute from map has the following callback script in "Reload Texture"


texcache -c ; opcook -F IN

But I had a bit more success running this python callback:


hou.hscript("texcache -c"); kwargs["node"].setHardLocked(True); kwargs["node"].setHardLocked(False)

since opcook -F INwasn't working on my own button.


Anyways, the file still locks in Win, was just trying to sort the reloading in Linux.

Cheers

Can you write to the file if you manually disable the OS read only attribute?

If so, a python script that tells the OS to do so first, if allowed, should do the trick.

I'm not running Windows at the moment so you would need to investigate yourself. Maybe you can find something here [stackoverflow.com].

It seems not obvious that the setHardLocked method does the same.

setHardLocked(on)
Turn this node’s hard-lock flag on or off. Locking a node saves its current cooked geometry into the node. If you unlock a hard-locked node, it will discard its locked geometry data and recook, computing its geometry from its inputs and parameters.