Subject: [netatalk-admins] Fiddling with Codepages
From: Patrik Schindler (poc@pocnet.net)
Date: Sat Jul 03 1999 - 17:22:31 EDT
Hi,
to adrian:
2.1.3 asun patches seem to push transfer performace from client to server up to 5MB/s according to Helios LANTest over 100MBit, downstream is somewhat slow with about 1,3MB/s.
Upstream has gotten 3MB/s faster here compared to version 2.1.1. Thank you, Adrian!!
(Measured with K6/233, 64MB RAM, 8MB/s harddisk according to hdparm, Linux Kernel 2.0.37, libc 5.4.44, netatalk 1.4b2/asun 2.1.3 with AppleShare 3.8.1/System 7.6.1/OT 1.3).
I lastly fiddled a bit with a separate (non-production) machine with Linux Kernel 2.2.10, glibc and netatalk 1.4b2/asun 2.1.3 with AppleShare 3.8.1/System 7.6.1/OT 1.3. That's what I discovered:
- A bug I described about a year ago has gone: it was, that the kernel syslogged around with "trying to read beyond filesystem" or a similar string when attacking a netatalked volume with FileList+ 1.0b21 (which creates pretty lists including the version string from the resource fork for feeding into mysql). The time I asked, I could not state clear if this was a kernel bug (recommended by a member of this list) or afpd's fault (who have I should asked this?).
It's gone, so thanks to the person(s) which kiled this bug.
- A picky program (Mausefalle, a Mac-MUA for proprietary german MAUS-Net) which read and wrote garbage on netatalked volumes now works fine. Here, too: Thank you, Adrian!
- Fiddling with codepage=maccode.iso8859-1 in AppleVolumes seems to get french and german umlauts right into the filesystem. Special Chars like the dot €, the folder Ÿ and other mac-specific chars would be translated to "gabage", so it's possibly better to really only translate the characters defined in the respective charset and leave the rest alone, escaped "the old way". Those escaped files with a codepage loaded show up fine in the Finder, accessing them doesn't work instead (File not found).
- Aliases now seem to work properly. Great! I'll try to dig into this a bit deeper while I try using it regularly from now on.
- Random syslog messages: 'setdirowner: chown -1/0 .AppleDouble/.Parent: Operation not permitted', even when accessing directories where all files (and folders) have rw(x) for the owner. This problem has been there since the early days of plain 1.4b2.
- I cannot verify problems with Trash Can #2 and such when accessing one volume with multiple users. With asun 2.1.1 the problems were some errors (-50) when trying to move something into the trash or a message "The object could not be moved to the trash, should it be deleted immediately instead?". I translated the message in english, 'cause I use a german system software, so apologize that I cannot quote the real error message here.
I don't know, if the problems are gone or if I do not discover them anymore, 'cause I'm the only one at the moment which uses a mixed-user volume.
>From the TODO:
>shortname support can be dealt with via symlinks to !<name> files.
I don't think of this as good idea. Think of RO-media. Create symlinks there?
What about showing all chars beyond the last period in the filename (if any), adding a 'Š' just before it and removing all chars immediately before this period until strlen() <32.
So the unix filename maybe stay quite long, the .AppleDouble entry maybe, too (for filesystem consistency) but the AppleShare Client only get's the short name. Any translation in this way gets cached until the particular child dies. I bet this will only seldom get a memory hog, most people have short filenames. At least here in germany ;-)
>ability to interact with hfs desktop databases (either by changing hfs or changing afpd).
You think about trashing the .AppleDesktop Directory and create Desktop DF and Desktop DB files?
> atalkd: it would be great if we had two capabilities --
three :-)
> 1) zones on single interfaces -- DONE!
> 2) ability to control which interfaces get routes between
> them.
3) routing for hop count > 2. I described this a time ago here.
:wq! PoC
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:54 EST