On Thu, Apr 26, 2018 at 12:45:41PM +0200, John Paul Adrian Glaubitz wrote:
Exactly. It works fine as is: root@elgar:~> uname -a Linux elgar 4.16.0-rc2-amiga-16784-ga8917fc #650 Mon Mar 5 15:32:52 NZDT 2018 m68k GNU/Linux root@elgar:~> mount /dev/sda1 /mnt -taffs root@elgar:~> ls -l /mnt | head total 0 drwx------ 1 root root 0 Mar 30 2001 Alt -rw------- 1 root root 1352 Mar 27 1997 Alt.info drwx------ 1 root root 0 Nov 16 14:39 C drwx------ 1 root root 0 Mar 27 1997 CS_Fonts drwx------ 1 root root 0 Mar 27 1997 Classes -rwx------ 1 root root 1132 Aug 14 1996 Classes.info drwx------ 1 root root 0 Feb 10 2004 Commodities -rw------- 1 root root 628 Jan 14 2002 Commodities.info drwx------ 1 root root 0 Apr 10 1999 CyberTools root@elgar:~> mount |grep affs /dev/sda1 on /mnt type affs (rw,relatime,bs=512,volume=:) root@elgar:~> There is nothing at the moment that needs fixing.
Funny, that... I'd been going through the damn thing for the last week or so; open-by-fhandle/nfs export support is completely buggered. And as for the rest... the least said about the error handling, the better - something like rename() hitting an IO error (read one) can not only screw the on-disk data into the ground, it can do seriously bad things to kernel data structures. Is there anything resembling fsck for that thing, BTW? Nevermind the repairs, just the validity checks would be nice... -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
