Quote:
1. Because it's GPL and we do not like it, especially if it would be a part of system and not contrib thing
2. Because the performance of ext3 relies a lot on large (very large) cache. Without cache it would be as fast as our current affs (this is the opinion of Marek Szypowski, who wrote ext2 handler for amiga)

Quote:

If you write non-GPL'ed ext2 filesystem and force it to use the unallocated memory as cache.

Regarding amiga file system....

Why can?t we just use Linux Ext3 format?? All Linux source is open right???

So how about a native AROS in Ext3 with a nice grub or lilo boot manager, and then maybe we need some tools to read (and write?) to fat32 and NTFS partitions.

Can this be done???

SuperTed

Quote:

SFS is here. You'll notice that michalsc is part of the project and has done some AROS work on SFS already (modified a file of macros for endian issues).

SFS would be great for AROS. It's one reason I put support for an SFS partition in the MBR partition handling.

From strap.c:


In other words, Any partition with an ID of 'SFS\0' will atomatically try to use a handler called sfs.handler, and any MBR primary partition of type 0x2f will get a partition ID of 'SFS\0'. I knew SFS was close and wanted to make sure some glue was in place so we could boot from it.

Yanosh: Thanks for pointing out MessyFilesystem. It does have the filehandler source. It currently just does FAT 12 and 16 and no long filenames (geared towards floppies). I suppose it could be modified with bits of the FAT code I pointed out to handle FAT 32 and long names.

Adam C. has said he would again work on FAT32 when he has the time. I think he just annoyed enough at it to eventually go back to it and finish it.

Again, if people want to donate $ to the FAT32, I'll gladly reopen it with new funding. Right now, the old FAT32 bounty from BTTC is now split up between SFS and AMD64 port.

Dammy
Head Troll
TeamAROS

Are we talking about "safe file system". The fast bulletproof system developed by some guy for amiga long ago.
Would be great but we still would?nt be able to access files from the windows partition.

Quote:

Can this be used?

http://main.aminet.net/misc/emu/msh-156.lha

Inside this archive there are some sources. I don't know if it needs some more sources not available there.

Since SFS already works on the Amiga, how about just "works in AROS the same as on the Amiga" for a description? That should cover it. Maybe add "whatever tools for SFS that are in the cvs must be converted to AROS" as well.

If you all want to fund FAT32 Bounty, that's do able.

However, I'm looking for a bounty description for SFS bounty in this thread. :)

Dammy
TeamAROS

Quote:


How about we start off with something simple like a FAT reader. i.e. a utility that just reads and allows copying from other fat disks/partitions.

Why do this ? Dunno, maybe it gives a bit of cross-platform ability I guess.

(I think i've mentioned this one before).


MrX


:K:

Filesystems can be the most complicated thing in the system... depends partly on how complicated the FS is. HFS used by Macs is REALLY FREAKIN' complicated. FAT isn't too bad by FS standards. There were several FAT handlers for the original Amiga. Unfortunately, none of them were open source.

Best bet for quick and dirty FAT support would be to port some existing code. I would probably go with the FAT code in the PS2Dev USB mass storage driver. PS2Dev projects are AFL v2 license which is supposedly compatible with the AROS license, so it could even go into the kernel.

A quick check shows it currently uses global variables, is limited to a single partition, and a limit of 16 files open at once. However, it does handle FAT12/16/32 and long filenames. It also has writing, but the writing is considered experimental. The disk accessing is via a set of macros:



The sector cache is remarkably similar to the cacheing in AFS (it sucks!). It seems to me that the code should be fairly easy to hack into an AROS handler skeleton. If no one else feels like trying their hand at it, I might.