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

There are issues with the bog standard CoreUtils port where
ls -l displays a Directory
drwxr--r--
regardless of it being locked or not.
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.

Eventually I will use the os version directly in my 'ls' as it has
aa wild card function built in, and it may be quicker to get
the file attributes then as well, reducing the size of the c file.
The unix wildcard ? character has to be changed to # but the *
stays the same.

I found a box with some old prm's so will be able to fit in some
reading on the swi soon.

Ronald

Ronald <chchron@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 --------

In article <mpro.ro2p7q00362150sy8.spamtrap@mw-software.com>,
Martin Wuerthner <spamtrap@mw-software.com> wrote:
> Ronald <chchron@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".

The original PRM skips over this, but I came across the (forgotten) *EX
Both Cat and Ex display the attributes. Ex perhaps a better display.

Yes I dont think there is any low level 'security' regarding
users/groups but if checking or setting permissions it sounds like
unixlib would be compatible.
If a directory was put in (RO)Lock by way of unix attributes, it would
probably undo the lock in a similar way.

There is strange stuff happening when svnadmin (1.14) creates an fsfs
repository that doesn't happen on linux.
svnadmin creates rev/0/0 file but later actions want a rev/0 file but
I think the rev/0/0 is the correct one.
Could be just corruption in the svn fsfs name handling rather than
a permissions issue.

I will set up a linux based svn server and see if the general operations
work then.

Thanks

Using svnadmin to create a repository on linux and copying it
back to RISC OS allowed me to progress to a commit.
Another bug appeared which was googlable and by switching off
repos-sharing in the repo config file cured that one.
I'm hoping that when I patch the config file permanently it
will help the second stages of 'svnadmin create' as well.
Thankfully there doesn't seem to be any issues when using the
RISC OS svn client against the linux server.
Ronald

In article <5a62ce589bchchron@yahoo.co.nz>,
Ronald <chchron@yahoo.co.nz> wrote:
> Using svnadmin to create a repository on linux and copying it
> back to RISC OS allowed me to progress to a commit.
> Another bug appeared which was googlable and by switching off
> repos-sharing in the repo config file cured that one.

Things are looking better now and that patch isn't required.
After many hours of tracing functions with printf statements
I found that svn 'posix' was renaming a read only file.
There is an OS/2 alternative that worked for RISC OS and a
WIN32 option to avoid the following fflush which also caused an
error.
svnadmin and it's default fs-type fsfs is working fine now.

Ronald