I’m getting errors when saving a USD file out of A2F onto a network drive. The console says:
2023-01-24 21:26:50 [Error] [omni.usd] Runtime Error: in Replace at line 142 of C:\b\w\ca6c508eae419cf8\USD\pxr\base\tf\safeOutputFile.cpp -- Insufficient permissions to write to destination directory 'p:\projects\epi\dialogue\scratch\edits\scratch_edit_01_v01_raw'
I confirmed it’s only the network filesystem by trying to save locally. Further, no, I do actually have permission to write in that network directory. That’s not the problem.
Since the error included a filename and line-number from what looks to be pixar sourcecode, I decided to try and track down the source and look into it further.
Eventually I happened upon the following github issue:
USD running as different user on Windows? · Issue #849 · PixarAnimationStudios/USD (github.com)
Note: the issue popped up in 2019. But the latest activity is two weeks ago at the time of writing this.
Note: it’s titled wrong. It’s not a UID issue.
The proposed workaround that shows up part way through having to do with Samba, is not sufficient as a fix.
Since NVidia is taking a certain amount of responsibility for USD’s future, I thought I’d suggest here, that NVidia evangelize an actual solution. Because it’s affecting your A2F product at a minimum.
My opinion (that I think NVidia should consider) follows:
User spitzak has correctly identified the programming error when he states:
IMHO all such errors should be deferred until it actually tries to write the file. Pre-testing to make sure it works is a bad idea, as the answer can change for any number of reasons between when the test is run and the attempt is made. I cannot blame the Windows developers for assuming software would not try to do this.
Bill Spitzak is correct. It’s always inappropriate to check permissions or even something as simple as a file’s existence, before running an IO operation. Because any other process or user could modify the filesystem between the check and the operation. The correct behavior in data-layer code, is always to run the IO operation and then react to the runtime error that may occur. It’s never okay to assume that the filesystem has not changed from the previous line of code. That’s true on Windows and on *nix. All the discussion of win32 API and Samba is misplaced.
I would categorize this as intermediate level programming knowledge. A pipeline engineer might not be aware of proper coding practices here. But a proper software engineer writing IO code definitely should. And it’s really a bit bizarre to find it in the USD codebase at this point. Further, in that thread you can see a lot of different people being very wrong about what is ‘safe’ IO behavior. The “safe” aspect of the code is supposed to be the relink of the temp file into final position, which is an atomic IO call. But I digress…
But seriously, this is where NVidia should step in and try and evangelize a proper engineering fix. Because it’s kinda critical to NVidia that USD actually work well.
Thanks for taking a look.