Re: Files, Directories, Resources, Operating Systems

[Timothy S. Nelson]

	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 <[EMAIL PROTECTED]> [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: [EMAIL PROTECTED]| 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-

Re: Files, Directories, Resources, Operating Systems

[Aristotle Pagaltzis]

* Charles Bailey <[EMAIL PROTECTED]> [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.

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

• 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.

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.

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.

Regards,
-- 
Aristotle Pagaltzis //