Recovery tool for JXFS

[vox]

ON popular demand, Recovery tool for JXFS

Its stated there will be a replacement file system when developers time allow it,
but simply some basic repair/recovery would be good meanwhile.

Or port PFS3

In the future - better and simpler file recovery, hard partitioning etc. tools.

[Belxjander]

We alerady have Media Toolbox for dealing with native partitioning...

the only capabilities for "simpler" and "easier" don't really happen from how that works without nerfing the existing design somewhat in my opinion.

I would like to see some non-destructive capabilities mysef, if it is at all possible to query a FileSystem and access part of it like a library for use with a partition editing tool getting the FileSystems themselves as plugins using a systemwide "filesystem list".

[vox]

We alerady have Media Toolbox for dealing with native partitioning...

the only capabilities for "simpler" and "easier" don't really happen from how that works without nerfing the existing design somewhat in my opinion.

I would like to see some non-destructive capabilities mysef, if it is at all possible to query a FileSystem and access part of it like a library for use with a partition editing tool getting the FileSystems themselves as plugins using a systemwide "filesystem list".

Well I might be a spoiled brat by advancements in Linux world, Android etc. but I somehow find install SLB with file system, partition in different formats, format and
hope for the best as fast and large file systems have no repair tools (real crash recovery, file saving ...) ... frustrating situation.

Yes, its all part of old heritage, but time to move on

Your proposal on having FS as library sounds nice, as I assume that way EXT4/NTFS could be added. Sounds too good to be true

As AW.net thread clearly summs it, its not happening often, but shit do happen and no worse think then data loss (except with dying of unavail
Amiga boards

[Belxjander]

FileSystems as libraries would render them problematic...

I would keep the existing FileSystem as a program approach.

The only thing that could possibly improve any filesystem development would be a "standard skeleton" as was done with libraries and devices.

I'm just happy that there IS sources available for SmartFileSystem and PFS3 to actually have a readable *working* template.

The only limitations on other tools would be access-locking for forcing a volume to restart from the beginning after a recovery or filesystem specific ool gets run (possibly an extension to what exists for presenting a "library" for raw access to a given volume?)

beyond that, the details are part of writing a filesystem... If there will be an HDWrench.library equivalent for handling partition block access in a standard basic way then access to partitions and volume locking could be included that way too.

One of the strengths of AmigaOS is the base modularity and how each modular part does only what it needs to do as best it can.
Any FileSystem tools may want to keep that as part of the build options as well

[chris]

Bear in mind there is a completely new filesystem architecture coming. Although what form it takes I have no idea!

I would expect anything new to be more like the library/device structure (function calling), than the existing "running program that listens for messages", but I don't have any inside knowledge nor do I know if that approach is even practical.

[Belxjander]

Well the only thing I see needed for FileSystems is a standard base set of FileSystem block read/write functions given a block device driver like scsi.device or sii34114ide.device or ramdrive.device

beyond that it is up to the FileSystem to handle block allocation, sizing and other meta and data stored inside the given partition metrics right?

Using a FileSystem library would work if there is a pre-existing "Handler" that used a library as plugins for each of the existing packet calls

Which is kind of what I see slowly getting built in the way the "new style" filesystem support works.

What I would personally like is to have an equivalent "AmigaDOS reference guide" listing on the Wiki so that I can try to work out what is essentially done for each "packet" or FileSystemObject being accessed.

What packets for file access, file metadata, directory access and metadata, other?

[tonyw]

There will never be DOS packets defined that allow you to interrogate or access the internal structures of the filesystem's metadata. To publicise that sort of information would immediately freeze the design so that it could never be changed again.

The internal structures are private for that reason - they have to evolve over time and they can't be changed if they have been released to the world. The higher-level DOS API is all that is required by applications programmers, and that has not changed.

All the old DOS packets have been replaced by library-type calls to new-generation filesystems. To date there are only a few new filesystems, and the older filesystems like FFS, SFS and JXFS are unlikely to ever be rewritten for the new API (there is just too much work involved in rewriting them). The new DOS functions are directly equivalent to the old DOS packets in most cases, but short-circuit much of the painstaking conversions and task context-swapping that the DOSPackets required. New-style filesystems do not (in general) handle DOS packets, but pass them back to DOS to emulate them as function calls.

The new filesystem API is defined in the DOS documentation (part of the SDK) and will be available to all when the updated SDK is released.

[Belxjander]

Great!!!, I'll await the updated SDK and try to put together some reference notes using what already exists towards building a newstyle filesystem, the only issue I have is an endianness conversion on read for existing metadata

With the above I was thinking more about getting function or hook callbacks and black-boxing any metadata specifically for testing alidity and giving relocation/resizing options