Safe place to store user-defined parameters

[TIG]

The parent-folder of Windows 'Temp' folder - 'Local' - IS clearly intended to be written to...
Many applications already make their own subfolders in it to store data more permanently that the Temp folder itself would allow...

If the MAC-guys don't want you writing to the user's 'T' folder's parent-folder, then they have never said so, and to make it non-writable would be straightforward for them...

I don't consider my Windows suggestion a 'hack' at all... the MAC side is less documented, but to date has always worked too...

@driven
The Plugins directory is NOT always writable by the user - this is always the possibility on a PC and before v2013 so it was on a MAC too.
So we can't confidently write any of our folder/files there - in fact we are now full circle because Fredo started this thread trying to find where to save data outside of this potentially limited tree...
Your ENV[HOME] is MAC only, BUT I agree it could be used for that OS by reconstructing the other tree elements from /Library/ - but then who can be sure they'll also remain 'constant' too ?
The equivalent for the PC is actually ENV["HOMEPATH"], but then returns say ' C:/Users/TIG', from which we'd need to construct the upwards tree towards /AppData/Local/XXX etc... This is more easily got working downwards from TEMP or TMP and makes no assumptions about paths ! It does expect Local and Temp to be writable - which is their purpose...

There are many places we cab write folders and files, knowing that the users will assuredly have permission - like their documents folder, their desktop, their 'temp' folders etc...
With the likes of Fredo's folder/files he wants it somewhere discreet and unnoticed...
The 'cookie.dat' file you refer to was originally written to an app specific subfolder inside 'Temp' or 'T' but the potential for it getting purged led me to move it into the container 'parent-folder' - on a PC that is expected to be written to...

[fredo6]

@TIG,

Your suggestion is interesting on Mac.

Actually, my problem is not so much to find a place where to write freely, but also a place:

• whose path is stable across time
• which is not erased without the user deciding

On Mac, with the convoluted name of the ENV["TMPDIR"] path, it remains to check it its parent remains stable through time.

Fredo

[driven]

VERSION AGNOSTIC MAC PATH... vain attempt...v2013

any_mac_or_SUv_path =
 File.dirname(File.expand_path(Sketchup.find_support_file("Shortcuts.plist"))) << ('/.MY_NAMESPACE/.my_hidden_file.*')

Returns:
` */Users/johns_iMac/Library/Application Support/Google SketchUp 6/SketchUp/.MY_NAMESPACE/.my_hidden_file.

[/Users/johns_iMac/Library/Application Support/Google SketchUp 7/SketchUp/.MY_NAMESPACE/.my_hidden_file.*

/Users/johns_iMac/Library/Application Support/Google SketchUp 8/SketchUp/.MY_NAMESPACE/.my_hidden_file.*

/Users/johns_iMac/Library/Application Support/SketchUp 2013/SketchUp/.MY_NAMESPACE/.my_hidden_file.***`

All mac users can write shortcuts... Shortcuts.plist may be dynamic but these are common fresh standard instal at that same path, so could be used as well or instead... "Autosave" "OldColors"

john

[thomthom]

@tig said:

The equivalent for the PC is actually ENV["HOMEPATH"], but then returns say 'C:/Users/TIG', from which we'd need to construct the upwards tree towards /AppData/Local/XXX etc...

Problem occur if the user has non-ASCII names - then it will fail.

[TIG]

Non-ASCII characters in file names/paths cause issues with some of Ruby's File commands [in the flavor of Ruby shipped with PC SketchUp].
So you will get a false ' false' result if you test for its existence, even when the folder actually exists:
So if you test for its existence, and then hope to make it if it doesn't exists, e.g.:
Dir.mkdir('C:/Users/Usersname/AppData/Local/XXXé') unless File.exist?('C:/Users/Usersname/AppData/Local/XXXé')
you will crash and burn because of the false false that results from the é !

The way to do this safely is...
begin Dir.mkdir('C:/Users/Usersname/AppData/Local/XXXé') rescue end
Which will make the folder, BUT if it does exists there's a silent error because it exists already...
Either way you'll get the specified folder !

This is not ideal but ca trap for some false false File test issues...

[thomthom]

But that doesn't help anything. You cannot write to that folder in any way.

[danielbowring]

@tig said:

BUT...
No one has still answered my question...
What is wrong with using the container folder for the ENV for the OS's user's 'Temp' folder?
That is easily found for either OS and is writable, like the Temp folder itself...
Once you have the path to the user's 'Temp' folder we can then make an app-specific subfolder to hold our temporary files...
AND from File.dirname(Temp) we can get the container-location into which we can make an app-specific subfolder to hold our 'permanent' files...
I do it without problems on all OS's - the rest of you seem to obsessed with finding 'the exact right folder that we must use', when in truth there are several valid possibilities, and my earlier posts cover much of this too... KISS ?

The temp directory is easy to get ( require 'tmpdir'; Dir.tmpdir) but only useful for temporary files.

If you're writing something to the temp directory with the intention of reading it later, you're doing it wrong. The temp directory is for files that have no consequence if they are removed at a later date. The temp directory is for writing, and reading only when you've been explicitly told to.

The "correct" place for persistent data for an application that is not part of the installation is the appdata location. These directories are separate for each user and guaranteed to be readable/writable for the associated user. This is normally were things like plugins/extensions would exist, also.

A good example of this (if you have it installed) is Sublime Text. (On windows) it is installed to %PROGRAMFILES%/Sublime Text, which contains all required binaries and application defaults. Then in %LOCALAPPDATA%/Sublime Text/ (or %APPDATA%/Sublime Text 2/ for st2 user level information is available, including plugins, settings, key configurations, ...

Driven has posted what appears to be the MAC equivalent of LOCALAPPDATA || APPDATA.

So, the search order for a path to write to should be: (keeping in mind I'm no MAC expert)

%LOCALAPPDATA% (win)
%APPDATA%      (win)
~/Library/???/Sketchup/  [or similar] (MAC) ["~" -> "/Users/<username>/"]
Sub-directory in SketchUp directory [plugin-data or similar] (if writable)
temp directory (last resort)

[thomthom]

@unknownuser said:

The "correct" place for persistent data for an application that is not part of the installation is the appdata location. These directories are separate for each user and guaranteed to be readable/writable for the associated user. This is normally were things like plugins/extensions would exist, also.

But as I mentioned - Ruby 1.8 cannot handle non-ASCII characters. Usernames might include Unicode characters and then all file operations on the user directory will simply fail.

[fredo6]

I will release the new versions of LibFredo6

• with ENV["LOCALAPPDATA"] on Windows
• with TIG's method on Mac, that is the parent directory of the ENV["TMPDIR"] folder. I think using ENV["HOME"] with some hidden subfolder would have been considered too intrusive.

These will be root folders into which I will create the LibFredo6 subfolders for persisting data.

I think in both cases these folder won't contain non-ascii characters, as they are defined and created by the system itself.

Fredo

[TIG]

On windows the Local path (ENV["LOCALAPPDATA"]) could return as say
f=ENV["LOCALAPPDATA"]) 'C:\Users\TIGé\AppData\Local'
which will return ' false' in a File.exist?(f) test when it actually exists, just because the user-name contains an accented character!

So use my 'safe' way [a few post ago] to make the folder, even if it exists already!

[danielbowring]

@thomthom said:

But as I mentioned - Ruby 1.8 cannot handle non-ASCII characters. Usernames might include Unicode characters and then all file operations on the user directory will simply fail.

All the more reason to update the ruby installation. The provided order would still "work" if you checked each of the directories existed (because the check would "simply fail"), but it's certainly no supplement for the actual feature.

It seems to be reoccurring that the SketchUp ruby API will gives you "clipped wings". I'm excited to see where it can go, but also impatient with its shortcomings (even though this one isn't really SU fault).

Side-note: No unicode support seems strange for something coming out of japan

[danielbowring]

@fredo6 said:

I will release the new versions of LibFredo6

• with ENV["LOCALAPPDATA"] on Windows
• with TIG's method on Mac, that is the parent directory of the ENV["TMPDIR"] folder. I think using ENV["HOME"] with some hidden subfolder would have been considered too intrusive.

These will be root folders into which I will create the LibFredo6 subfolders for persisting data.

I think in both cases these folder won't contain non-ascii characters, as they are defined and created by the system itself.

Fredo

ENV["LOCALAPPDATA"] may contain non-ascii characters, as it contains the current users username. Also, you should use ENV["LOCALAPPDATA"] || ENV["APPDATA"] so you can support XP at no extra effort

Bonus:

[thomthom]

Just to test things I created a user account "tæst" under Windows7. And ran some tests in the Ruby Console:

ENV['HOMEPATH']
\Users\t‘st

ENV["LOCALAPPDATA"]
C;\Users\t‘st\AppData\Local

ENV["APPDATA"]
C;\Users\t‘st\AppData\Roaming

file = File.join( ENV['LOCALAPPDATA'], 'FooBar.txt' )
C;\Users\t‘st\AppData\Local/FooBar.txt

File.open( tempfile, 'wb' ) { |file| file.puts 'Hello world' }
Error; #<Errno;;ENOENT; (eval);0;in `initialize'; No such file or directory - C;\Users\t‘st\AppData\Local/FooBar.txt>
(eval)
(eval);0;in `open'
(eval);0


ENV['TEMP']
C;\Users\TST~1\AppData\Local\Temp

tempfile = File.join( ENV['TEMP'], 'FooBar.txt' )
C;\Users\TST~1\AppData\Local\Temp/FooBar.txt

File.open( tempfile, 'wb' ) { |file| file.puts 'Hello world' }
nil

Interesting observations:

Most ENV has some strange character replacements. Is this a Ruby thing?

ENV['TEMP'] returned a path in the format of the old DOS 8.3 format. And this could be written to.

ENV.each { |k,v| puts "#{k}\t#{v}" }
ALLUSERSPROFILE	C;\ProgramData
APPDATA	C;\Users\t‘st\AppData\Roaming
CommonProgramFiles	C;\Program Files (x86)\Common Files
CommonProgramFiles(x86)	C;\Program Files (x86)\Common Files
CommonProgramW6432	C;\Program Files\Common Files
COMPUTERNAME	ARC-CU-10-09
ComSpec	C;\Windows\system32\cmd.exe
FP_NO_HOST_CHECK	NO
HOMEDRIVE	C;
HOMEPATH	\Users\t‘st
LOCALAPPDATA	C;\Users\t‘st\AppData\Local
LOGONSERVER	\\ARC-CU-10-09
NUMBER_OF_PROCESSORS	8
OS	Windows_NT
PATHEXT	.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE	x86
PROCESSOR_ARCHITEW6432	AMD64
PROCESSOR_IDENTIFIER	Intel64 Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL	6
PROCESSOR_REVISION	1a05
ProgramData	C;\ProgramData
ProgramFiles	C;\Program Files (x86)
ProgramFiles(x86)	C;\Program Files (x86)
ProgramW6432	C;\Program Files
PSModulePath	C;\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC	C;\Users\Public
SESSIONNAME	Console
SystemDrive	C;
SystemRoot	C;\Windows
TEMP	C;\Users\TST~1\AppData\Local\Temp
TMP	C;\Users\TST~1\AppData\Local\Temp
ULTRAMON_LANGDIR	C;\Program Files\UltraMon\Resources\en
USERDOMAIN	arc-cu-10-09
USERNAME	t‘st
USERPROFILE	C;\Users\t‘st
windir	C;\Windows

The TEMP path seem to be the only one using this format.
So, question is, is it possible to monkey-patch this so one can extract the user directory in DOS8.3 format and use that to replace the mangled paths of the other variables?

And what does it return under other Windows versions? (Win8, Vista, XP)

What about chineese/japanese types or characters - does the same thing apply?

[thomthom]

@unknownuser said:

Also, you should use ENV["LOCALAPPDATA"] || ENV["APPDATA"] so you can support XP at no extra effort

What folders does this yield on XP? Under Win7 it's both in the user directory.

[fredo6]

I will use the parent of ENV["TMPDIR"] only on Mac. Apparently, this directory has a long cryptic name, which I assume will only contain valid characters.

On Windows, this is more of a problem is ENV["LOCALAPPDATA"] cannot be manipulated from Ruby dues to non Ascii characters. It's not only for creating subfolders there, but also to manage filepaths of files to be created and updated.

The best I can do is to check if the username contains non-ascii characters and then simplify the name to Ascii, and create a folder with that simplified name in C:\users. This really becomes convoluted!!

There must be a trick however, because when Sketchup installs, it sets the default file locations pointing to the "MyDocuments" folder, whose name also contains the username (something like C:\Userfiles\<username>\Documents\). But maybe these locations are not used from Ruby.

Fredo

[thomthom]

@fredo6 said:

The best I can do is to check if the username contains non-ascii characters and then simplify the name to Ascii, and create a folder with that simplified name in C:\users. This really becomes convoluted!!

Creating random folder directly in the location where user folders are? I don't think people would too happy about this. I'd like to explore if we can get the 8.3 filename for the appdata folder.

@fredo6 said:

There must be a trick however, because when Sketchup installs, it sets the default file locations pointing to the "MyDocuments" folder, whose name also contains the username (something like C:\Userfiles\<username>\Documents\). But maybe these locations are not used from Ruby.

Correct - SketchUp itself has no problems with Unicode paths. It's the Ruby 1.8 core.

[fredo6]

@thomthom said:

@unknownuser said:

Also, you should use ENV["LOCALAPPDATA"] || ENV["APPDATA"] so you can support XP at no extra effort

What folders does this yield on XP? Under Win7 it's both in the user directory.

Actually as I use both, LOCALAPPDATA first and then APPDATA.

For info, on WindowsXP, ENV["APPDATA"] is defined and uses the old Windows user directory in the form of C:\Documents and Settings\<username>\Application Data.

Fredo

[thomthom]

@fredo6 said:

For info, on WindowsXP, ENV["APPDATA"] is defined and uses the old Windows user directory in the form of C:\Documents and Settings\<username>\Application Data.

Got a full list of ENV variables under XP?

Btw- if I recall correctly "Documents and Settings" is localized to the user's language, isn't it? (without the shim that Vista,Win7, win8 uses)

[fredo6]

We could also substitute <username> in the paths by

• Default on Win7, Vista, Win8
• All users on XP

At least this will avoid the problem of unicode in the username.

Fredo

[thomthom]

@fredo6 said:

We could also substitute <username> in the paths by

• Default on Win7, Vista, Win8
• All users on XP

At least this will avoid the problem of unicode in the username.

And the setting would not be per-use - but per computer. ...which might not be a big issue since the plugin folder is shared by all users.

But again I raise my concern that XP paths might be translated. "All users" I think is "Alle brukere" in Norwegian XP. (I can dig out my old XP machine and test.)