File permissions puzzle

[alancfrancis]

I'm not sure exactly how to articulate this so bear with me if there's a bunch of rambling that turns out to be irrelevant :-)

I am working on a little git client for AmigaOS 3.x and one of the things I do regularly is create repos inside FS-UAE or the Mac (or Ubuntu) host OS on a "folder-based hard disk" so I can check that either the AmigaGit can read things that it can't yet create, or that "real git" can read things it *can* create.

Again not sure if the back story is relevant, but just to explain what I'm seeing.

git creates blob files in repo/.git/objects/<sha> and on macos and linux those files are read only by design. In the screenshot you can see one such blob on ubuntu host OS. "inside the amiga" under FS-UAE the file looks like it appears to be available for RWED, so that seems overly open, yet fine for my purposes - the amiga should be able to read the read-only files.

What I was seeing however when I ran my AmigaGit client was failures to read the objects. I did a lot of debugging of my own code and couldnt quite figure out what I was seeing, but when I drop out to the CLI and even just try and dump the file out to check it wasnt corrupted, TYPE reports that it cannot dump the file because it "write protected".

So....
1. the file in the host OS file is read only
2. LIST shows the file in the amiga as readable *and* writable (I think?)
3. when I try to Open() the file for READING, Open() fails.
4. when TYPE tries to open the file for READING, it complains that its not WRITABLE.

I wondered if anyone had any insight into any part of this - either LIST reports something different from the host OS, why neither I nor TYPE can read a file that LIST thinks is write protected.

The key issue for me, of course is that a readable file on the mac is not a Open()-readable file on the emulated amiga, the rest is just debugging questions :-)

Thanks,

Alan

p.s. Its an emulated A4000 with KS3.2.1 and OS 3.2.1 and a bucketload of RAM

[DisasterIncarna]

Directory mode access for the emulator? whats the file permissions looking like outside of emulation for those files? still read/write/normal?

[alancfrancis]

Not quite sure what you’re asking. As far as the host OS is concerned they are

444 r- - r - - r - -

Like in the screenshot ? Maybe I’m misunderstanding the question ?

[DisasterIncarna]

shouldnt there be a w in there somewhere on the host side, or the emulated side cant write

ie:
-rw-r--r-- or rw-rw-rw


your screenshot is implying it cant write, perhaps for that reason even tho the emulated side "looks" like it should work.

[alancfrancis]

git creates the files as read only. You never write back to a blob, just read it over and over. But what I’m seeing is that I can’t read the read only file from FS-UAE. Neither can TYPE but TYPE (which is like CAT on the Amiga) weirdly complains about it not being writable (it’s not, but why does TYPE care?). It shouldn’t need to be writable to read it so I’m not sure why TYPE is complaining.

[DisasterIncarna]

hm, that is bizarre if anything id expect an error with TYPe if it cant lock/open the file in question, it is indeed weird it complaining about write access.

is there a similar issue when opening the file with say multiview?, ed? or just Type.

Maybe Type just opening the file for read access also triggers the write side of things? no idea how normal amigados commands work, but i recall in Blitz Basic, theres 2 ways to open a file, OpenFile() opens a file for both read and write access, and i think ReadFile() is read only. No idea what Type is doing tbh, probably gonna need one of the amigados guru's here who might know if Type is somehow triggering read and write at the same time when opening a file or if other weirdness is at play.

[alancfrancis]

I’ll try multiview. Was just looking for anything that could open a binary file without complaint I’ll also look into ReadFile. Open() has two modes MODE_OLDFILE AND MODE_NEWFILE but I don’t think they are read/write flags, just whether to complain if a file doesn’t exist.

[alancfrancis]

Yeah multiview says the same thing - "file is write protected", and it is on the HOST OS, but UAE says it isnt, and then also why does multiview care

[alkis]

Hmm, try disabling creation of .uaem files.

https://fs-uae.net/docs/options/uaem-write-flags

[alancfrancis]

And I checked and Open does not have "read only mode".

/* Mode parameter to Open() */
#define MODE_OLDFILE	     1005   /* Open existing file read/write 
				     * positioned at beginning of file. */
#define MODE_NEWFILE	     1006   /* Open freshly created file (delete 
				     * old file) read/write, exclusive lock. */
#define MODE_READWRITE	     1004   /* Open old file w/shared lock,
				     * creates file if doesn't exist. */

I wondered about maybe trying

BPTR lock = Lock("filename", ACCESS_READ);
BPTR file = OpenFromLock(lock);

to see if I can get pure read-only access to the file.

Will consult some DOS oracles. Seems the "why does UAE say the file is RWED when its RRR" issue is secondary. The underlying host is protecting me and indocating the file is read only, but AmigaDOS is always trying to open for read+write access.

[alancfrancis]

OK update from an actual amiga, create a file,

PROTECT file r

to make it readonly, try and open it with

Open()

, opens fine. TYPE can cat it no bother. So this is purely something inside UAE.

Will experiment with removing the uaem file as Alkis suggests, and will further experiment using

PROTECT

to try and make Amiga permissions match the actual host OS ones.

[DisasterIncarna]

hopefully it will work out, hate it when seemingly simple things puts a spanner in the works.

[alancfrancis]

OK last update with findings.

1/ switching of uaem files made no difference.
2/ changing the file inside emulation with

PROTECT filename r

to make it match the host OS 444 *did* work.

So I'm putting all this together and drawing some conclusions, which may be wrong, but have to be my operating assumptions going forward.

1/ FS-UAE is not respecting any permissions on the host OS, it just sets everything to RWED by default, regardless of whether the file is readonly on the host OS. This may be a bug, or not, but it doesnt seem to be something I can change..

2/ Inside the Amiga (real? and emulated) if the file protection bits suggest the file is available for writing, Open() opens it for reading and writing, somehow under the covers. It sees its writable so wants to make sure the file handle is usable for writing.

3/ When the amiga bits say read only and that matches the host OS, it opens only for reading, and all is right with the world.

4/ When the amiga bits inside UAE say RWED, Open() tries to open for read/write but the underlying host OS wont allow that because its really readonly, so I see the behaviour I am seeing.

In short it seems to me like the dos Open() function tries to check the protection bits and open correctly, but since the protection bits under UAE don't match the host OS protection bits, boom.

So the last question is whether this failure of UAE to respect the actual host protection bits is real (not just my wrong conclusion) and if so, is it a bug or a missing feature.

[alancfrancis]

So the last question is whether this failure of UAE to respect the actual host protection bits is real (not just my wrong conclusion) and if so, is it a bug or a missing feature.

Hah. https://github.com/FrodeSolheim/fs-u....cpp#L555-L557

That answers that :-)

[alancfrancis]

https://github.com/FrodeSolheim/fs-uae/issues/158. cc @FrodeSolheim :-)