That's probably it. Most servers expect directories with:MDFS doesn't allow setting any of WR/WR on directories, only setting/clearing of P, L, and the never-used-for-anything M bits. Appears to be treated as an error if you try.Perhaps I should only be doing this fir directories?
This applies both to *ACCESS and to set_object_info, where if the client is doing it on a directory they need to be supplying zero (or 0x10 to set the Lock bit).
Dxxxxx to be traversable, renamable, and deletable(if empty)
DLxxxx to be traversable, not renamable, and not deletable
and clients almost universally set to ------ or -L----, and often only just store D and L (or mask out not-DL).
So if a server is allowing the WRwr bits to signify something it has to cope with the normal API never setting them. The L4FS on RISC OS allows the WRwr bits to indicate things (L4FS hides directories from non-owners if the 'R' bit is unset on the host filing system), but that's only visible to the server itself, it doesn't make them visible or modifyable over the network API.
*ACCESS * WR/R is expected to set all files to WR/r and all directories to D/ at the same time (though there's nothing stopping directories getting a hidden WR/r as well), similarly:
*ACCESS * LR/R is expected to set all files to LR/r and all directories to DL (again, there's nothing stopping directories getting a hidden R/r as well).
The MDFS usefully allows D and -D to specify just directories or just non-directories:
*ACCESS * DL - lock all directories, don't change any files
*ACCESS * -DWR - set all files to WR, don't change any directories
If a user really wants to set the access to "/" they should be allowed to. It's a common programming paradigm to do: OSCLI "ACCESS "+filename$:OSCLI "DELETE "+filename$. While the file unexpectedly becoming WR/r doesn't stop it being deleted, the principle of least surprise recommends that it shouldn't.
Statistics: Posted by jgharston — Mon May 20, 2024 11:03 pm