MiSTer FPGA Forum

I want to make a way to access Linux file system from Amiga.
I know how to make it in general. It requires to write a filesystem driver. Basically a simple and tiny driver is required which will write request to shared memory and then wait for reply.
The problem is that i don't know Amiga OS. I need a developer who is familiar with Amiga OS and can help me to assign a proper resources and other internal things and write such driver.
We can re-use part of this driver:
https://github.com/niklasekstrom/a314/t ... are/a314fs
It works similarly to what i want but we don't need complexity of that HW. We simply can create a shared memory between Amiga and Linux.

If it will be done, then Minimig will get a fast file exchange like UAE.

I'm not a developer, but interested in your approach.
By exposing a filesystem you refer to a block-level SCSI-like device?

Maybe you should post in https://eab.abime.net/

mbo77 wrote: ↑Tue Jun 23, 2020 8:06 am I'm not a developer, but interested in your approach.
By exposing a filesystem you refer to a block-level SCSI-like device?

Not quite - this would be a filesystem handler - i.e. something that lives in L: rather than Devs:
Think of it more like NFS, only communicating through a closely-coupled memory window instead of over a network cable.

File systems are non-trivial to implement, issues like file locking, character encoding of filenames, illegal filename chars, metadata, buffers and cache...

kolla wrote: ↑Tue Jun 23, 2020 1:35 pm File systems are non-trivial to implement, issues like file locking, character encoding of filenames, illegal filename chars, metadata, buffers and cache...

None of those. Just need to adapt the driver from link i've posted. If it would be windows or linux driver then i would do it myself.

It looks like it builds for me. Let me know what you need adjusted.

c:\dev\a314\Software\a314fs>build.bat

c:\dev\a314\Software\a314fs>vc a314fs.c -S -c99 -IC:\vbcc-2020.06.16.bin\targets\m68k-amigaos\include -IC:\Amiga\NDK_3.9\Include\include_h -LC:\vbcc-2020.06.16.bin\targets\m68k-amigaos\lib -LC:\Amiga\NDK_3.9\Include\linker_libs -o a314fs.asm

c:\dev\a314\Software\a314fs>python comment_out_sections.py

c:\dev\a314\Software\a314fs>vc bcpl_start.asm a314fs.asm bcpl_end.asm -IC:\vbcc-2020.06.16.bin\targets\m68k-amigaos\include -IC:\Amiga\NDK_3.9\Include\include_h -LC:\vbcc-2020.06.16.bin\targets\m68k-amigaos\lib -LC:\Amiga\NDK_3.9\Include\linker_libs -nostdlib -o a314fs

c:\dev\a314\Software\a314fs>python patch_a314fs.py

c:\dev\a314\Software\a314fs>del a314fs.asm

c:\dev\a314\Software\a314fs>file a314fs
a314fs: AmigaOS loadseg()ble executable/binary

c:\dev\a314\Software\a314fs>

I've adjusted some paths, to point to /media/fat/Amiga/shared as the folder for sharing.
The compiled binaries are in the release:
https://github.com/apolkosnik/a314/releases/tag/rel1

I've compiled that under windows, rather than going the easy route with the docker on linux.

apolkosnik wrote: ↑Wed Jun 24, 2020 3:51 am I've adjusted some paths, to point to /media/fat/Amiga/shared as the folder for sharing.

Sorry, haven't been here some time and didn't see your replies as i was busy by studying the subject (since no one wanted to help me). Shares now are working. Just need to polish it.

This is awesome news - shipping content back and forth by updating and copying HDF images over SAMBA is getting old. <G>

Thank you!

Great news!

Yep, will help a lot indeed ! Thanks, Sorge !

I don't understand how Workbench get notification that folder is changed. Currently you don't see the changes in folder after operations, so you have to choose update in menu to see the changes.
Any ideas?

I'm not sure it does. If you have a Workbench folder window open, then use the CLI to copy a <folder>.info into it, it doesn't just show up.

AFAIK, Workbench doesn't do the automatic refresh. I think it only works for new volumes that will show up on the main Workbench window, such as when you insert a new floppy into the disk drive. Other Workbench replacements might be capable of doing updating on changes content.

When you delete the file or folder (icon->delete) then it disappear from window. And when you drag the icon to copy it, it will appear normally in new place.
But in case of my implementation the content of opened window doesn't change till i choose window->update
I see WB sends ACTION_INFO about once per 1-2 seconds, so i was thinking it can get some change notifications which will force update the window. But so far, i couldn't detect which field can be used for that. May be i'm looking in wrong place.

Another, more serious problem:
If i try to remove the folder and it's not empty, then workbench remove EVERYTHING from shared folder. This is weirdest behaviour i ever seen. WB examines every directory entry, delete everything, then gets parent directory and deletes everything there and till it hit the root of shared folder!
I couldn't identify the reason of such behaviour. The only workaround i could make is to delete the selected folder internally and return "success" result.

Sorgelig wrote: ↑Sat Jun 27, 2020 4:03 pm Another, more serious problem:
If i try to remove the folder and it's not empty, then workbench remove EVERYTHING from shared folder. This is weirdest behaviour i ever seen. WB examines every directory entry, delete everything, then gets parent directory and deletes everything there and till it hit the root of shared folder!
I couldn't identify the reason of such behaviour. The only workaround i could make is to delete the selected folder internally and return "success" result.

I can guess - is there a ".." in the folder, that points to parent folder on the linux directory, and that from Amiga side looks like a subfolder named ".."?

kolla wrote: ↑Sat Jun 27, 2020 9:05 pm I can guess - is there a ".." in the folder, that points to parent folder on the linux directory, and that from Amiga side looks like a subfolder named ".."?

"." and ".." aren't transferred to Amiga. Amiga uses ACTION_PARENT message explicitly wanting to find the parent of current folder, so it's not like simple opening of ".."

kolla wrote: ↑Sat Jun 27, 2020 9:03 pm http://aminet.net/package/util/wb/AutoUpdateWB

Very interesting info. Although it doesn't explain why it's not updated automatically.
But i will try to find what's the difference from native folders.

according to WB sources, standard DeleteDiskObject() also calls UpdateWorkbench(), so basically it should work with any file system. Weird...

So this is only an issue with Workbench, and not CLI and DOpus etc? The one to ask is Olaf “olsen” Barthel, he’s the one currently maintaining workbench.library, and he’s usually very helpful.

Hi Sorge ! Piru and Thor could help you - they master the dos. They are on the amiga.org forum.
Cheers !

kolla wrote: ↑Sat Jun 27, 2020 11:23 pm So this is only an issue with Workbench, and not CLI and DOpus etc?

It's only WB window content update issue. DOpus correctly updates after copy/delete.

Which OS version, 3.1.4?

3.1

Well, i identified a half of deletion problem. I didn't check the locks before delete. Now it doesn't delete locked objects. In WB 3.9 deletion works ok (honestly i didn't test before on 3.9), while 3.1 doing weird thing: If dir is not empty then it copy the lock and then deletes the content, then when it comes to deletion of dir itself it fails since lock haven't been freed. After fault, it frees the lock. So at the end, the content of dir is deleted (if there are internal dirs then they correctly deleted) while dir itself isn't. Then second attempt to delete this dir finally deletes it.

Just tested 3.1.4.
Good news: it automatically updates window when file is copied/deleted.
Bad news: all files paired with .info are totally invisible on shared disk. Even if you select "show all", they are still invisible in WB. Only if i rename .info to something different then both original file and its .info addon becomes visible. In DirOpus - no problems.

fixed .info problem in 3.1.4
So it seems sharing is correctly working in 3.1.4 now.