the detailed folders returning incorrect data

[Mark Waddingham]

On 2016-07-01 17:14, Paul Dupuis wrote:
> 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.
...
> I'm sure that's more background info that you either wanted or have 
> time
> for Mark :-)

It is interesting - I guess it would be nice if MS had designated a 
'this folder must always be writable for application data' but, as 
you've found out, there are so many choices here now that it must be a 
bit of a nightmare for those managing networks of Windows computers too!

The 'detailed files' dictionary entry is definitely wrong in that it 
should explain about the situation with Windows. The engine does map the 
MS-DOS read-only attribute into the permissions - as that is per-file 
and independent of user - however, in this case, the access is being 
controlled by the ACLs on the files (which, as mentioned before, are 
substantially more complicated!).

I'd be concerned about trying to write something which maps ACLs into 
the UNIX permissions words as they are two entirely different models - 
and thus whilst such a thing might be useful for some use-cases, chances 
are there would be large number of use-cases where the mapping was 'not 
quite right'.

As a point of reference, Cygwin (the port of lots GNU and related UNIX 
utilities to Win32) do use ACLs to emulate the POSIX user permissions - 
however, that mapping is heavily tied to the 'cygwin environment' i.e. 
it makes sense within Cygwin, but no so much sense outside.

The best approach, perhaps, would be to work out how to return the ACL 
information for a file on Windows so Script can be written to process it 
and 'dig out' the specific information it requires (writing the checking 
routines in script makes the most sense, since it allows much easer 
tweaking for specific cases which might arise for your specific 
use-case). In your case this appears to be:

    - Can the currently running user read the given file

    - Can the currently running user write to the given file

    - Can the currently running user create a file in the given folder

This is probably something somebody could tackle when Infinite LiveCode 
appears - although this is perhaps going to be an exercise in attempting 
to fully understand the ACL and DACL APIs Win32 have... They are not the 
most straightforward of beasts as Fraser and I discovered whilst trying 
to fix the 'elevated permissions' bug in the engine which appeared on 
Win7 and above (because MS removed one 'access-right' by default from a 
certain operation between Vista and 7 in order to apparently plug a 
security hole). Although, to be fair, reading the information is 
probably going to be easier than trying to setup ACLs for a specific 
operation - particularly one which has to work across privilege 
boundaries!

So, anyway, the dictionary entry certainly needs to be made clearer on 
this point; and it is probably best for you to continue with the 'trying 
to write a file' type approach for now - with hopefully the potential 
for a 'nicer' solution in the future.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps