OTHOME\temp

appuq · 2024-07-15T15:42:18+00:00

There was an error rendering this rich post.

Experts

I have a module in which on installation I allocate a folder in OTHOME\TEMP\<MYMODULENAME>\myfile.txt

this was all fine and dandy until I started noticing this in my current version on service re-start I see all temp folders getting deleted and re-created. It is fine for OT products but I chose to store an important file in that xecmqellus .

Assuming this is a new change can someone confirm where I could store a file for persistence? I see webreports now doing what they need on appData.Or was this always the case in Oscript and maybe we just got lucky all along and never noticed this

All this extra file does is reveal the upload directory configured to a Java module so it can place the file to be uploaded there correctly. At the time of dev, I and my colleague settled on this design because there wasn't a way for the Java code to reach out to the connected database

Assuming we cannot change the way we source that info is there a way when a service restart occurs I can make my module recreate the file I see it remembers to create the folder… or should I recode to move to appData or is there some place on the file system one can do this…

Find more posts tagged with

Comments

Dave Carpeneto

Hiya - I've not noticed that temp gets cleaned out, but I'm not surprised / I've seen that in a variety of other systems (I remember dying inside when the exact same thing happened to me in SunOS in the 90s, and I've never put anything in temp that wasn't "temp" since 😖).

There's a variety of places to put stuff. Most modules inside OT seem to put stuff inside the module folder itself (for example OTHOME/core/module/activeview/sampleperspectives ).

All this extra file does is reveal the upload directory configured

Worst case you could have your module dump $KERNEL.SystemPreferences.GetPathGeneral( "UploadDirectory", "" ) to whatever your Java utility is set up to read from on init, no? 🤷‍♀️

appuq

@Dave Carpeneto thanks will re code :)

Greg Griffiths

@Dave Carpeneto as you mention some modules use AppData, some use their own module folders, it would be nice to see some "Best Practice" approaches shared with Partners / Devs so we know which models to follow, config for code review tools like Solarwinds etc, is something on that available ?

appuq

BTW the CS server as I tested is 24.1 .I have several other machines in our lab that are different none of them remove and recreate temp.

Dave Carpeneto

@Greg Griffiths : I think we'd have to have a best practice before we document what that practice will be 😉

@appuq : Given this I'll have a look about to see what's going on / what has changed. Maybe this was unintentional? 🤷‍♀️

Matthew_Pinkney

Hello,

The change to make the tempdir volatile was done purposely as a part of cloud readiness and containers.

There are two new calls to use.

1. $FileUtils.GetTempDirWithName (“namespace”) - will create and
return a directory within the base temp directory specifically for your
namespace. This directory is for temporary data and will be emptied at server startup.

2. $FileUtils.GetAppDataDirWithName (“namespace”) - will create and
return a directory within the base appdata directory specifically for your namespace. This directory is for persistent data and will not be touched on server startup or system upgrades.

David Henshaw

@Matthew_Pinkney Thank you very much for that info. I've always understood that appdata is the only place one should be storing any file based data that needs to be persisted between restarts.

I know when we started our certification for OT Cloud that one of the team (Wendy or Juliano) provided us a "cloud solutions thou must not do X" document.

Tid bits of internal working information like you've posted are great - what would be "greater" is if these were all relayed via as others have commented as "best practice" guide….something that articlates "hey everyone, here are the OSCript etc methods and approaches you're encouraged to use".

Greg Griffiths

@David Henshaw is that document publicly available ? or available to other Partners etc ?

David Henshaw

Not sure Greg, it's called "Requirements for certified Cloud Solution Extensions" and to my knowledge has only been provided to SolEx partners at time of undergoing their Cloud certification with OT.

Personally, I see no reason it couldn't be shared with wider development community - though some of the recommended/required points are less likely to be relevant to those developing for non OT Cloud deployment (i.e. private cloud/on-prem).