Safe place to store user-defined parameters

TIG

What speaks against using an iterative search?


> # Find an existing and writable directory where to store user data.
> dir = [
>   ENV["LOCALAPPDATA"],                    # Windows ver. 6+
>   ENV["APPDATA"],                         # Windows
>   File.join(ENV["HOME"].to_s, ".local", "share"), # Free desktop standard
>   File.join(ENV["USER"].to_s, "Library", "Application Support"), # OS X
>   "."                                     # Fallback; exists always, where as ENVs may not.
> ].compact.map{ |path| File.expand_path(path) } # expands links and path separators
>  .find{ |path| File.exists?(path) && File.writable?(path) }
> DATA_DIR = File.join(dir, "MyPlugin")
>

I already posted something similar [but with a bigger choice of fall backs] for deciding on your 'TEMP' folder... AND on PC or MAC you can write subfolders/files one folder 'up the tree' from the TEMP folder, so you can put any custom-subfolder there...
I've never had a failure [yet ].
Many programs have freely writable folders in these locations...
On a PC it's the 'C:/Users/Username/AppData/Local/' folder [which in turn contains your 'Temp' folder], on a MAC is a system generated 'seemingly-gobbledygook-folder-name-tree' [which in turn contains your 'T'[emp] folder]...

Here is some explanation of a PC's three 'User Folders'...

Roaming is the folder that would be 'synchronized' with a server if you had logged into a domain with a 'roaming profile' (enabling you to log into any computer in a domain and access your favorites, documents etc).
For example: Firefox stores its information here, so you could even have the same bookmarks between computers with a roaming profile.

Local is the folder that is specific to that computer.
Any information here would NOT be synchronized with a server.
This folder is equivalent in XP to C:\Documents and Settings\User\Local Settings\Application Data.

LocalLow is effectively the same as the Local folder... but it has a lower 'integrity level'.
For example: when 'protected mode' is 'on' IE8 can only write to the LocalLow folder.

fredo6

Anyone has an idea if ENV["LOCALAPPDATA"] is defined on Mac?

Fredo

driven

%(#FF0000)[**# SU returns =>

ENV["LOCALAPPDATA"]
nil**]

fredo6

@driven said:

%(#FF0000)[**# SU returns =>

ENV["LOCALAPPDATA"]
nil**]

hanks
And what about ENV["APPDATA"] ?

driven

%(#FF0000)[**# SU returns =>

ENV["APPDATA"]
nil**]

 ENV
{"PATH"=>"/usr/bin;/bin;/usr/sbin;/sbin",
 "TMPDIR"=>"/var/folders/rp/b9k42l5x7xngx_8tckgs0zdr0000gn/T/",
 "SHELL"=>"/bin/bash", "HOME"=>"/Users/johns_iMac",
 "USER"=>"johns_iMac",
 "LOGNAME"=>"johns_iMac",
 "SSH_AUTH_SOCK"=>"/tmp/launch-0•••••/Listeners",
 "Apple_Ubiquity_Message"=>"/tmp/launch-RCcmJV/Apple_Ubiquity_Message", "Apple_PubSub_Socket_Render"=>"/tmp/launch-BeHprC/Render",
 "DISPLAY"=>"/tmp/launch-HUlKie/org.macosforge.xquartz;0",
 "IG_ROOT"=>"/Applications/SketchUp 2013/SketchUp.app/Contents/Resources",
 "SHLVL"=>"14",
 "PWD"=>"/",
 "_"=>"/usr/bin/open",
 "__CF_USER_TEXT_ENCODING"=>"0x1F5;0x08000100;0\n",
 "COMMAND_MODE"=>"unix2003"}
>

fredo6

Thanks John.
I m afraid I'll store default parameters in /tmp, which seems to be only safe place defined on Mac (TMPDIR does not look very stable across OSX session.

Fredo

driven

TMPDIR is only cleared if coded to do so, /tmp is for temporary files and is purged on reboot....

SketchUp use /tmp for active tool log file , and TMPDIR for crash-logs [without a cap]

Aerilius

That is a temporary folder. We have to ask John how long temporary files stay there, but usually one cannot assume that temporary files stay until after a reboot. It is only exceptional for Windows that temporary files stay for "long" (I once found years old files).

driven

@aerilius said:

That is a temporary folder.

A lot of mac users never reboot, so for them they are semi-permanent, for the life of a software release or until SU 'bug-splatts'.

however, most the files in there, overwrite themselves regularly... etc. they are meant to be momentary.

Unfortunately for me, I learnt this the hard way by loosing my entire dev folder that I had in there at one point.

now I use it for the images/files needed only during a session, even then I write backups to my 'Plugins' folder, which I only overwrite on next use of the tool.

access, FIFO is meant to be faster, which is good for temporary logging, and image compositing.

john

slbaumgartner

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

fredo6

@slbaumgartner said:

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

I understand.
But where can the persistent parameters be saved on Mac?
What are other applications doing?

Fred

driven

Apple applications must be self contained to meet the 'Approved' status that SU is attempting to gain.

If they don't 90% of mac users will get a warning that 'SU' is 'unapproved' and 'potentially harmful', this puts a LOT of people off.

That's why everything is moving back into SU's App Folder in the User space it's also why they added Extension Manager.

As far as Apple are concerned Users should only ever need to access an app from within the app and should not be required to ever need to add anything externally.

For it's Users. SU provides the all the paths you need to supply an SU Plugin to run on a mac, use them.

If Users have move stuff around, that's their problem and SU and Apple are happy.

If your developing on a mac, you can change permissions to get around some of the sandboxing and you can then compile and 'package' helpers so Uses can benefit from your workarounds, if your on a PC it's a nightmare to take alternate routes.

If you keep all your files in your Plugins Directory and the SU at supplied external paths, I can't see a problem.

SU and Apple are happy, you can be happy too.

john

Aerilius

That's very easy, if the OS vendor finger-points at the one who plays bad, then everyone has to try to play nice.
User's personal data (settings on one side and user data (works, templates, user-managed plugins on the other side) belong to the user level also on other operating systems (of which Windows is only one special example, I even do not use Windows). Then there would not be permission problems. It has often enough been pointed out that plugins in the Windows version SketchUp are in the wrong place.

The permission problem story on Windows has its origin that it was designed as a single user OS at a time when also security models where basic or non-existing. Microsoft decided to keep compatibility instead of "deprecating" older applications (or applications that don't follow the new rules), which lead to this inconsistency.

slbaumgartner

@fredo6 said:

@slbaumgartner said:

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

I understand.
But where can the persistent parameters be saved on Mac?
What are other applications doing?

Fred

On a Mac under OS X, the conventional/approved place for user configuration parameters is a .plist file in ~/Library/Preferences. The file name starts with a dot-separated sequence like a reversed domain name that identifies the relevant app, and then adds more segments to specify what about that app. For example, com.trimble.sketchup.fredo.magictool.plist.

There are API calls for storing and retrieving info from plist files, but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

driven

@slbaumgartner said:

but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

@Steve,
that's exactly what this pair does, your entry in the com.sketchup.SketchUp.plist

 result = Sketchup.write_default "section",
   "variable", "my_value"
result = Sketchup.read_default "section",
 "variable", "default"

in the .plist that shows as

	<dict>
		<key>variable</key>
		<string>"my_value"</string>
	</dict>

john

slbaumgartner

@driven said:

@slbaumgartner said:

but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

@Steve,
that's exactly what this pair does, your entry in the com.sketchup.SketchUp.plist

 result = Sketchup.write_default "section",
>    "variable", "my_value"
> result = Sketchup.read_default "section",
>  "variable", "default"
>

in the .plist that shows as

	<dict>
> 		<key>variable</key>
> 		<string>"my_value"</string>
> 	</dict>

john

Which leaves me somewhat confused about what fredo is seeking to accomplish. Unless you are determined to keep your info somewhere separate from SketchUp's "defaults", what's the problem with using these methods?

Steve

Aerilius

I think for simple configurations (keys, values etc.) Sketchup.write_default is the ideal solution because it uses the API, and the API makers care about that it works.
But sometimes one wants to store more data or even files, so called "user data" (vs. "config").
I don't know what Fredo has in mind.

fredo6

Aerilius is right.

There are situation where you can persist parameters in the Sketchup section of the registry and some where this is not desirable or not possible.

My scripts use the registry for some parameters, and files for some others. By principle, it is never advised to overload the registry of a system, as it may easily get corrupted.

In addition, there are cases where you simply need to store files, not data, say components, materials, etc... that are created on the fly by the plugin based on user inputs.

Windows makes provision for a 'application data' location on disk. On MAC, there must also be a 'natural' place where such user files are stored. For instance, Microsoft Office use templates and other option files and they are not stored in the registry.

I think Sketchup cannot continue to propose only the Sketchup root directory to store files underneath. All new versions of operating systems are very picky on security and won't let you access this area from a program or embedded script like Ruby.

The objective of this post was to see whether the developer community would have ideas and would agree on a convention, because I assume many scripts are in the same situation.

Fredo

Chris Fullmer

I'm recently beginning to learn Mac - would:

~/Library/Application Support/

be the folder that is comparable to Application Data on Win?

driven

hi
have a look at this, it explains Apples viewpoint.

http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html

Apples basic philosophy is
@unknownuser said:

Every app is an island

this includes any plugins written for any app.

Apple are moving away from any need for "uninstaller software", as far as they're concerned if a User or the "App Store", trashes or updates an app, then 'all' the files associated with the outgoing 'app version' will be gone on next restart of the mac. To achieve this, it's limiting 'where' you can easily write to, and for 'app approval' you have to prove this can be achieved.

If I remove anyones 'Plugin' for SU, I expect 'all' it's support files to disappear from my system. So does Apple.

I have one 'Plugin' that moves items all over the place, but if I remove it or even just disable it from the 'Extension Manager' it puts everything back in place and deletes it's 'watch-file'. If I then restart it it writes everything back again. The only thing that ever resides external to SU folder structure are temporary or the outcome of User input i.e. document files I want to keep.

john