Ronald <
chc...@yahoo.co.nz> wrote:
> I have run into permission translation problems on a gccsdk project. I
> will develop my own ls command further for research purposes. On the RISC
> OS 5.28 side, 'protecting' a directory from access only is reflected in
> the info option as L.
You cannot protect a directory from any access apart from deletion, and that
is achieved by locking it. You cannot stop anyone from adding files to a
directory or deleting files from it, at least not on a local FileCore disc.
> The access option for a directory displays the same
> regardless. even though the whole contents has been locked from that point
> I guess this means a directory has no attributes other than 'L'ock.
It has the usual user R/W and public R/W attributes, and they can be
changed, but they do not do anything on a local disc, so the Filer sets just
the "Locked" flag when you choose "Protected".
> There are issues with the bog standard CoreUtils port where ls -l displays
> a Directory drwxr--r-- regardless of it being locked or not.
That is to be expected. Unix does not have any concept that matches the RISC
OS "Locked" state, so Unixlib has to ignore it. Locking is orthogonal to
read/write access. On a Unix system, an individual file cannot be protected
against deletion. Whether you can delete a file depends on the access
details of its parent directory, since conceptually, it is the directory
that is modified.
> Possibly not
> a good example of unixlib though as it fails to display dot names like
> .svn (/svn) My own unixlib version of using readdir() has no problem with
> dot names so it is not happening everywhere.
ls does the right thing here. It is part of its specification that it does
not display dot names, unless you specify -a.
--
Martin Wuerthner MW Software
http://www.mw-software.com/
------- RISC OS Software for Design, Printing and Publishing --------