[boost] Re: Filesystem problem

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-23 00:45:04

Hi Beman,

Beman Dawes wrote:

>  >how can I get rid of a read only file? At present it seems to be
>  >impossible?
> 
> Yes, at the moment it is impossible with the filesystem library.
> 
> [Warning: half-baked ideas follows. I don't even know if it is spelled
> writeable or writable.]
> 
> If we can figure out portable behavior that will work on POSIX and
> Windows, and is likely safe if not useful on other operating systems, then
> perhaps we should add something to <boost/filesystem/operations.hpp> like:
> 
>     bool is_writeable( const path & );
> 
> On Windows, the return would reflect the state of the read-only attribute
> bit.
> 
> On POSIX, the return would reflect the Write permission bit for the most
> restrictive user class which applies.

Will this be the same as result of POSIX call

   access(filename, W_OK)

? The question is that I'm not sure what "most restrictive user class which
applies" means. The simple semantic is:

  - if user if the owner of the file, return user's "w" bit
  - if user if in the group which owns the file, return group's "w" bit
  - otherwise, return "other's" "w" bit

The question if what's "user" --- there's "real" user id and "effective"
user id. The latter really determines access rights, but the former is what
'access' function tests. I'm not sure that difference between real and
effective id must be addressed by filesystem lib, since it's very platform
dependent -- and only effective id must be used. But if so, the semantic
above must be implemented manually, as 'access' uses real id.

> On O/S's which have no concept which usefully maps into is_writeable,
> return true.
> 
> Note that a true return from is_writeable() does not guarantee that a file
> or directory can actually be written to by the program.
> 
>     void set_writeable( const path &, bool value = true );
> 
> On Windows, would set the read-only attribute bit accordingly. May throw.
> 
> On POSIX, would set the write permission bit for the most restrictive user
> class which applies.  May throw.

I see that "man chmod" says:

  The  effective  UID  of the process must be zero or must match the owner 
  of the file.

So it only makes sense to set users's write bit. Attempt to set group's
write bit when user is not owner will fail.

> Comments?

This seems a good addition. 

Is it likely that someone will soon ask for 'x' bit support --- which sets
'x' bit on POSIX, and does nothing on Windows?

- Volodya