1. Forum
  2. Usenet
  3. COMP.SYS.ACORN.PROGRAMMER

  • Directory permissions

    From Ronald@21:1/5 to All on Fri Jan 6 13:20:54 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Wuerthner@21:1/5 to Ronald on Fri Jan 6 17:45:26 2023
    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 --------

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to Martin Wuerthner on Sat Jan 7 10:55:52 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to All on Sat Jan 7 15:31:09 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to Ronald on Mon Jan 9 21:20:07 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)