Re: Files, Directories, Resources, Operating Systems

Front page | perl.perl6.language | Postings from December 2008

Re: Files, Directories, Resources, Operating Systems

Thread Previous | Thread Next

From:

Timothy S. Nelson

Date:

December 10, 2008 20:42

Subject:

Re: Files, Directories, Resources, Operating Systems

Message ID:

alpine.LRH.1.10.0812111529040.3228@gwalcmai.nelson.org.au

 	I''ve been playing with similar sorts of problems when creating an OO 
model for packaging metadata, that could supposedly represent the data from a 
.rpm or a .deb or whatever.

 	The first thing I did was set up a method where if we're outputting 
eg. an RPM, it will mark every piece of metadata it uses, and then afterwards, 
the core system will emit warnings about all the things it didn't use. 
Something similar could possibly be done; we'd simply need to give the user 
control as to where the warnings end up.

 	Note that I also agree with the guy who said that we need 
system-specific calls, and then an abstraction layer on top of that.

On Wed, 10 Dec 2008, Aristotle Pagaltzis wrote:

> * Charles Bailey <bailey.charles@gmail.com> [2008-12-10 03:15]:
>> It may well be that a fine-grained interface isn't practical,
>> but perhaps there are some basics that we could implement, such
>> as
>>
>> - set owner of this thing
>> - (maybe) set group of this thing
>> - give owner|everyone|?some-group the ability to read
>>   from|write to|remove|run this thing
>> - tell me whether any of these is possible
>> - make the metadata for this thing the same as the metadata for
>>   that thing
>> - tell me when this thing was created|last updated
>
> There are many problematic suggestions here. Some examples:
>
> ? Unix does not track file creation datetime at all.

 	Emit a warning.

> ? The concept of making a file runnable doesn?t even exist on
>  Windows: that property is derived from the filename extension.

 	So when they read it, make a guess based on the extension, and when 
they write it, emit an error.

> ? Delete permission on a file is a concept that doesn?t exist on
>  Unix. To be able to delete a file, you instead need write
>  permission on the directory it resides in.

 	So when they read it, figure it out, and when they write it, emit an 
error.

> Furthermore, in Win32, files and directories can inherit
> permissions, so the fact that a file has certain effective
> permissions does not mean that these permissions are set on
> the file itself. But if you set them on the file itself, you
> dissociate it from the inheritance chain. So reading permissions
> and then setting them the same, without changing anything, can
> still have unwanted side effects. Or if you try to make the API
> smart, and so make it set permissions only when they constitute
> a change from the effective permissions, then conversely the user
> no longer has a way to dissociate the file from iheritance if
> that *is* what they wanted. So the concept of inheritance must
> be exposed explicitly.

 	Or, you could pick a consistent model, and then let the user use the 
lower-level interface if they want to be more specific.

> This is the primary issue I was thinking of when I said that some
> differences between Win32 and Unix have such pervasive effects
> that it seems impossible to provide even a rudimentary abstract
> interface.

 	Try "rudimentary *optional* abstract interface", where the other 
option is system-specific.

 	:)

---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland@wayland.id.au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----

Thread Previous | Thread Next