the detailed folders returning incorrect data

Paul Dupuis paul at researchware.com
Fri Jul 1 11:14:11 EDT 2016


On 7/1/2016 7:49 AM, Mark Waddingham wrote:
> I just wonder if there is a better away to approach the problem you
> are trying to solve; or whether there is actually a problem to solve
> at all (which isn't already solved by thorough error checking and
> handling).

The problem I am working on has to do with reading and writing a
preferences file and a license file across platforms and within
platforms across versions of the OS and even within a platform (Windows)
and OS version, the wide range or ways corporate and university customer
take to secure computers in their labs and on their networks where
"typical" folders may be read only or otherwise restricted.

While the problem is predominately on the Windows side, we have run into
a university owned OSX box(es) in a lab where the Preference folder was
read only.

So, we also, for legacy reasons, need to look into multiple locations
for older versions of the license file or preference file that may have
been installed by (a) older versions of our software; (b) administrator
command line installs using site desktop management and deployment
software line LanDESK; (c) where current OS Manufacturer guidelines say
to put them (admittedly, not changed much on OSX, but has over time on
Windows and Windows moves more and more to a "sandboxed" model)

So, I walk through a list of locations, looking for existing files, if I
find it, and it is readable and writable, I use it. If I don't find it
OR it it is not read/writable, I also want to walk through a list of
location (different order) to find the first writable folder I can store
our preferences and license file in.

It is no longer the case where you can 100% rely of
specialFolderPath("preferences") [OSX] and specialFolderPath(26) [Win]
100% of the time in the real world out there.

I was hoping to use the detailed files and  detailed folders to check
read/write permissions vs the classic test file trick (which can also
suffer from changing over time). Given it not available on Windows, I
will go back to the classic model of testing folder write-ability by
trying to write a temp test file and deleting it if successful. And to
test existing file read/write by trying to open it for update and if no
errors, then closing it. Obviously, on successive writes, whether via
"put ... into URL ..." or via "open file ...", we check for errors in
case permissions have changed, disk space has been exceeded or the user
pulled the USB cable or whatever.

I am leaning towards writing everything into a sub-folder of the users
"Documents" folder as that seems to be the only place "guaranteed" by
both Apple and Microsoft to fully accessible to the user as them evolve
their OSes more and more to a locked down/sand boxed model.

I'm sure that's more background info that you either wanted or have time
for Mark :-)





More information about the use-livecode mailing list