[llvm-commits] [llvm] r156591 - in /llvm/trunk: include/llvm/Support/FileSystem.h lib/Support/Unix/PathV2.inc lib/Support/Windows/PathV2.inc

Eric Christopher echristo at apple.com
Wed May 16 10:53:52 PDT 2012


On May 15, 2012, at 8:19 PM, Aaron Ballman <aaron at aaronballman.com> wrote:

> On Tue, May 15, 2012 at 6:58 PM, Eric Christopher <echristo at apple.com> wrote:
>> 
>> On May 15, 2012, at 4:54 PM, Nick Kledzik <kledzik at apple.com> wrote:
>> 
>>> I thought this FileSystem layer was supposed to abstract away OS details.  But this change puts the Unix permissions model right in the interface.  How is the new 'mode' parameter supposed to be implemented on Windows?
>>> 
>> 
>> I have no idea. I don't know the windows api here.
> 
> I don't honestly think it's needed on Windows.  We would specify the
> security information in the call to CreateFile (it accepts a security
> descriptor), but Windows doesn't have the same notions about file
> permissions as *nix variants do.  There's no "executable" bit, for
> instance.  No sticky bits, etc.  Most of the time, the default
> security attributes are what you want.  About the only exception would
> be "read-only" files, for which you could use a Win32 API
> (SetFileAttributes) to do it instead of mucking about with user
> security settings.
> 

Figured it'd be something like that.

> Personally, I agree that it doesn't make sense to expose mode to the
> API directly like we're doing.  It's just not a generic concept that
> exists everywhere.

Access restrictions do, however, I admit I just took the easy way out in this case since I knew Nick was working on an output file class that would ultimately do what I want :)

-eric




More information about the llvm-commits mailing list