afpfs-ng-devel Mailing List for afpfs-ng
Status: Alpha
Brought to you by:
alexthepuffin
Menu
▾
▴
afpfs-ng-devel — Discussion about various technical issues with afpfs-ng.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(8) |
Feb
(9) |
Mar
(16) |
Apr
(1) |
May
(19) |
Jun
(5) |
Jul
(4) |
Aug
(6) |
Sep
(7) |
Oct
(14) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(4) |
Mar
(14) |
Apr
(6) |
May
(2) |
Jun
(14) |
Jul
(11) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Riadh D. <rdj...@or...> - 2012-01-19 16:22:49
|
Hi Derrik, Thanks for your help, my problem was that I tried to mount the afp volume over vpn. On the local network it works without problems. I'll try your patch to connect over VPN tonight. Riadh On 18/01/12 08:05 PM, Derrik Pates wrote: > Riadh: > > When I try to connect to an AFP volume (netatalk server), I > receive the > error : > Login error: Unknown error, maybe username/passwd needed? > > In the system log I have : > afpfsd: Libgcrypt warning: missing initialization - please fix the > application > > Any idea how can I fix this problem ? > Thanks in advance. > > > Hm, I've never seen that happen with the advanced UAM code enabled > before. Can you try applying the attached patch to your afpfs-ng > sources? Just download the patch, and from the afpfs-ng source > directory, run: > > patch -p1 < ~/Downloads/afpfs-ng-gcrypt_init.diff > > Then rebuild and reinstall afpfs-ng, and let me know if you still have > the same problem. Unfortunately there haven't been any new releases in > nearly 4 years, so I don't know what the outlook is for a new one, but > hopefully this will get you going. > > -- > Derrik Pates > de...@no... <mailto:de...@no...> |
|
From: Derrik P. <de...@no...> - 2012-01-19 01:36:03
|
Riadh: > When I try to connect to an AFP volume (netatalk server), I receive the > error : > Login error: Unknown error, maybe username/passwd needed? > > In the system log I have : > afpfsd: Libgcrypt warning: missing initialization - please fix the > application > > Any idea how can I fix this problem ? > Thanks in advance. > Hm, I've never seen that happen with the advanced UAM code enabled before. Can you try applying the attached patch to your afpfs-ng sources? Just download the patch, and from the afpfs-ng source directory, run: patch -p1 < ~/Downloads/afpfs-ng-gcrypt_init.diff Then rebuild and reinstall afpfs-ng, and let me know if you still have the same problem. Unfortunately there haven't been any new releases in nearly 4 years, so I don't know what the outlook is for a new one, but hopefully this will get you going. -- Derrik Pates de...@no... |
|
From: Riadh D. <rdj...@or...> - 2012-01-16 08:08:24
|
Hi,
When I try to connect to an AFP volume (netatalk server), I receive the
error :
Login error: Unknown error, maybe username/passwd needed?
In the system log I have :
afpfsd: Libgcrypt warning: missing initialization - please fix the
application
The command to connect :
# afp_client mount -u rdjebrouni -p - -a DHX2 10.10.1.20:PRODUCTION
/mnt/production
AFP Password:
Mounting 10.10.1.20 from PRODUCTION on /mnt/production
Login error: Unknown error, maybe username/passwd needed?
Nothing is reported when running afpfs daemon in debug mode :
# afpfsd -df
Starting up AFPFS version 0.8.1
Informations about the remote server :
# afpgetstatus 10.10.1.20
Server name: NAS-PROD-AFP
Machine type: Netatalk2.2.1
AFP versions:
AFP2.2
AFPX03
AFP3.1
AFP3.2
UAMs:
DHX2
Signature: ff62ffff03ffff79ffff3045ffff620b
Any idea how can I fix this problem ?
Thanks in advance.
Riadh
|
|
From: Ronald P. <pij...@ds...> - 2011-10-24 18:50:24
|
Hi Amanda, You probably need libfuse-dev. Ronald Op 24 okt 2011, om 17:16 heeft Amanda Hickman het volgende geschreven: > I'm trying to set up afpfs-ng on Ubuntu 11.10 and encountering errors > at the configuration stage. The checks run through the fuse check, > which fails: > checking for fuse.h... no > configure: error: FUSE is not installed. To build without fuse, > configure with '--disable-fuse' > > But ... I'm running fuse-utils and libfuse2 version 2.8.4-1.4ubuntu1. > > Is there a way for me to help afpfs-ng find fuse? > > Thanks, > Amanda > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Afpfs-ng-devel mailing list > Afp...@li... > https://lists.sourceforge.net/lists/listinfo/afpfs-ng-devel > |
|
From: Amanda H. <ama...@th...> - 2011-10-24 15:46:37
|
I'm trying to set up afpfs-ng on Ubuntu 11.10 and encountering errors at the configuration stage. The checks run through the fuse check, which fails: checking for fuse.h... no configure: error: FUSE is not installed. To build without fuse, configure with '--disable-fuse' But ... I'm running fuse-utils and libfuse2 version 2.8.4-1.4ubuntu1. Is there a way for me to help afpfs-ng find fuse? Thanks, Amanda |
|
From: Derrik P. <de...@de...> - 2009-01-05 19:20:38
|
Alex deVries wrote: > It is probably that it has never been tested. I'll have a look if I can > hunt down an x86_64 machine, but I don't have one readily available. If you can't, let me know. I could provide you SSH access to my home workstation, or a VM running in VMware running CentOS 5/x86_64 or something. -- Derrik Pates de...@de... |
|
From: Alex d. <ale...@gm...> - 2009-01-05 19:16:51
|
On 5-Jan-09, at 12:57 PM, Derrik Pates wrote: > Alex, list, etc.: > > Has afpfs-ng been tested on any x86_64 system? I've tried building the > 0.8.1 release and current CVS against Ubuntu intrepid, but the code > just > pukes and dies (afpfsd dies with SEGV, mount_afp dies with libc > complaining of a buffer overflow and causing a stack trace and > SIGABRT). > I'm just trying to figure out if it's just intrepid breaking things > (possible), or if x86_64 has never in fact been tested. It is probably that it has never been tested. I'll have a look if I can hunt down an x86_64 machine, but I don't have one readily available. - Alex |
|
From: Derrik P. <de...@de...> - 2009-01-05 19:07:54
|
Alex, list, etc.: Has afpfs-ng been tested on any x86_64 system? I've tried building the 0.8.1 release and current CVS against Ubuntu intrepid, but the code just pukes and dies (afpfsd dies with SEGV, mount_afp dies with libc complaining of a buffer overflow and causing a stack trace and SIGABRT). I'm just trying to figure out if it's just intrepid breaking things (possible), or if x86_64 has never in fact been tested. -- Derrik Pates de...@de... |
|
From: Alex d. <ale...@gm...> - 2008-08-15 12:45:12
|
No, I hadn't! Somehow I never got an email from tracker. I'll put this patch in when I next can. Thank you for this. Mind you, I warn you that CVS is highly, highly unstable, and I wouldn't actually be running what's in there now. I'll code review and run the whole thing through valgrind before I release 0.9.x. I had hoped to stabilize this sooner, but I need to focus on getting the interface to support KDE going. I'm also going to be on vacation (biking in France) until September 14, so don't expect much email from me for awhile. Just don't confuse my vacation with this being a dead project... - A On 15-Aug-08, at 6:38 AM, Ralph Böhme wrote: > Hi Alex, > > have you seen this one: > http://sourceforge.net/tracker/index.php?func=detail&aid=2000728&group_id=179882&atid=890942 > > It's still not in CVS as of now. > > Regards > -Ralph > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Afpfs-ng-devel mailing list > Afp...@li... > https://lists.sourceforge.net/lists/listinfo/afpfs-ng-devel |
|
From: Ralph B. <ra...@rs...> - 2008-08-15 11:07:46
|
Hi Alex, have you seen this one: http://sourceforge.net/tracker/index.php?func=detail&aid=2000728&group_id=179882&atid=890942 It's still not in CVS as of now. Regards -Ralph |
|
From: HAT <ha...@fa...> - 2008-07-23 14:12:38
|
Sorry. I experimented on the connection from Mac OS 9.2.2 to Mac OS X 10.5.4. >------------------------------------------------------- >#define AFP_SERVER_NAME_LEN > >Apple Filing Protocol Programming Guide >Page 11 > >> A string in Pascal format of up to 32 characters. > >A leading-octet of Pascal string is length. > >#define AFP_SERVER_NAME_LEN 31 about servername: abcdefghijklmnopqrstuvwxyzABCDE possible to access abcdefghijklmnopqrstuvwxyzABCDEF possible to access abcdefghijklmnopqrstuvwxyzABCDEFG impossible to access #define AFP_SERVER_NAME_LEN 32 >------------------------------------------------------- >#define AFP_MACHINETYPE_LEN > >Apple Filing Protocol Programming Guide >Page 11 > >>A string in Pascal format of up to 16 characters that describes >>the file server's hardware and software but has no significance to AFP. > >#define AFP_MACHINETYPE_LEN 15 maybe, #define AFP_MACHINETYPE_LEN 16 -- HAT |
|
From: Alex d. <ale...@gm...> - 2008-07-19 14:35:39
|
HAT, Okay, I've committed about half of these; the others overlap with some other local changes, and I'll wait with committing those until I have some other things done. By the way, you have some changes to files in the 'fuse' directory, which has now disappeared. You may want to prune your cvs checkout. Thanks for your help! - A On 18-Jul-08, at 2:48 PM, HAT wrote: > Alex, > >> That all seems pretty reasonable. I'll apply it tonight. Have you >> tried this code with long volume names? > > The following volumename is ok. > > > "ÀÀÀÀÀÀÀÀÀÀ" > 30Bytes as decomposed-UTF8 > "HAT のパブリックフォルダ" > 34Bytes as precomposed-UTF8 > "がぎぐげごがぎぐげご" > 60Bytes as decomposed-UTF8 > "각각각각각각각각각각" > 90Bytes as decomposed-UTF8 > > > "HAT のパブリックフォルダ" means "HAT's Public Folder". > Public Folder's volumename is precomposed-UTF8. > This is Mac OS X's bug. > Other volumename is decomposed-UTF8. > > When too long foldername is made a shared folder, Finder becomes > unstable. This is Mac OS X's bug. > > The folder that is normally shared can be normally mounted by afpfs- > ng. > > >> I'll verify it against a Mac OS 9 system, but I can't see how that >> would be broken. > > I do not test Mac OS 9 at all because MacJapanese is not supported. > > -- > HAT > |
|
From: HAT <ha...@fa...> - 2008-07-18 18:49:03
|
Alex, > That all seems pretty reasonable. I'll apply it tonight. Have you > tried this code with long volume names? The following volumename is ok. "ÀÀÀÀÀÀÀÀÀÀ" 30Bytes as decomposed-UTF8 "HAT のパブリックフォルダ" 34Bytes as precomposed-UTF8 "がぎぐげごがぎぐげご" 60Bytes as decomposed-UTF8 "각각각각각각각각각각" 90Bytes as decomposed-UTF8 "HAT のパブリックフォルダ" means "HAT's Public Folder". Public Folder's volumename is precomposed-UTF8. This is Mac OS X's bug. Other volumename is decomposed-UTF8. When too long foldername is made a shared folder, Finder becomes unstable. This is Mac OS X's bug. The folder that is normally shared can be normally mounted by afpfs-ng. > I'll verify it against a Mac OS 9 system, but I can't see how that > would be broken. I do not test Mac OS 9 at all because MacJapanese is not supported. -- HAT |
|
From: Alex d. <ale...@gm...> - 2008-07-18 17:06:48
|
HAT, That all seems pretty reasonable. I'll apply it tonight. Have you tried this code with long volume names? I'll verify it against a Mac OS 9 system, but I can't see how that would be broken. And congratulations for hunting through my code, I hope that wasn't too unpleasant. - A On 18-Jul-08, at 11:33 AM, HAT wrote: > I wrote a patch for current CVS HEAD. > > I replaced a lot of AFP_VOLUME_NAME_LEN with AFP_VOLUME_NAME_UTF8_LEN > because neither classic-volumename nor UTF-volumename are > distinguished > mostly in sources. > > I tested Mac OS X 10.5.4 - Fedora 9. > This run well. > > It is also needed to examin AFP_SERVER_NAME_LEN and > AFP_SERVER_NAME_UTF8_LEN. > > -- > HAT > <cvs20080718-volname-length.patch.gz> |
|
From: HAT <ha...@fa...> - 2008-07-18 15:33:39
|
I wrote a patch for current CVS HEAD. I replaced a lot of AFP_VOLUME_NAME_LEN with AFP_VOLUME_NAME_UTF8_LEN because neither classic-volumename nor UTF-volumename are distinguished mostly in sources. I tested Mac OS X 10.5.4 - Fedora 9. This run well. It is also needed to examin AFP_SERVER_NAME_LEN and AFP_SERVER_NAME_UTF8_LEN. -- HAT |
|
From: Alex d. <ale...@gm...> - 2008-07-17 02:43:11
|
Okay, I have committed the suggested changes to CVS. Thanks! - A On 16-Jul-08, at 1:16 PM, HAT wrote: > Alex, > >> Yes, that doesn't seem right and I cannot remember where I got that >> data from. I probably wrote that when I started this two years, and >> in looking through the 3.1 docs it looks incorrect. I may have taken >> this from netatalk. > > netatalk's volumename length is buggy. > http://www003.upp.so-net.ne.jp/hat/netatalk/cjk.html > >> Is the solution just to increase the length of >> AFP_VOLUME_NAME_UTF8_LEN to 255? >> >> It looks like AFP_VOLUME_NAME_LEN should be 27. >> >> Are there similiar problems with server name lengths? > > Your sources are not clear which bare string or Pascal string. > Pascal string include leading one byte. > > ------------------------------------------------------- > Apple Filing Protocol Programming Guide > Page 16 > >> AFPNames are encoded in conformance to the Unicode standard (UTF-8), >> which uses 16-bits to encode more than 65,000 characters. >> To keep character coding simple and efficient, the Unicode Standard >> assigns each character a unique numeric value and name. >> To help when converting from UTF-8 to other script systems, >> AFPNames begin with a four-byte text encoding hint that specifies >> the script that was originally used to compose the name. >> The text encoding hint is followed by a two-byte length field >> specifying the length of the UTF-8 encoded name that follows. > > ------------------------------------------------------- > #define AFP_SERVER_NAME_LEN > > Apple Filing Protocol Programming Guide > Page 11 > >> A string in Pascal format of up to 32 characters. > > A leading-octet of Pascal string is length. > > #define AFP_SERVER_NAME_LEN 31 > > ------------------------------------------------------- > #define AFP_SERVER_NAME_UTF8_LEN > > Apple Filing Protocol Reference > Page 97 > >> UTF-8ServerName (AFPName) >> AFPName containing the UTF-8-encoded name of the server. > > #define AFP_SERVER_NAME_UTF8_LEN 65535 > > This is not realistic. > If UTF-8ServerName is 255 over, this volume should be disregarded. > > #define AFP_SERVER_NAME_UTF8_LEN 255 > > ------------------------------------------------------- > #define AFP_VOLUME_NAME_LEN > > Apple Filing Protocol Reference > Page 101 > >> For AFP 2.x, this command returns volume names in ANSI format >> with a maximum length of 27 bytes. > > #define AFP_VOLUME_NAME_LEN 27 > > Maybe, the classic client has length of 31 bytes for volumename. > 4 bytes have been reserved for suffix so that the same volumename > may exist. > > 31 - 4 = 27 > > ------------------------------------------------------- > #define AFP_VOLUME_NAME_UTF8_LEN > > Apple Filing Protocol Reference > Page 101 > >> For AFP 3.x, this command returns volume names in UTF-8 format >> with a one byte length byte specifying any length up to 255. >> Note that the Finder limits setting volume names to no more than >> 27 characters. > > #define AFP_VOLUME_NAME_UTF8_LEN 255 > > Do not confuse "character" with "byte". > Generally, > One Latin character is 2 bytes as UTF8. > One CJK character is 3 bytes as UTF8. > > 27 CJK characters are 81 bytes. > > If character is decomposed, it is more complex. > > ------------------------------------------------------- > #define AFP_SIGNATURE_LEN 16 > > ok. > > ------------------------------------------------------- > #define AFP_MACHINETYPE_LEN > > Apple Filing Protocol Programming Guide > Page 11 > >> A string in Pascal format of up to 16 characters that describes >> the file server's hardware and software but has no significance to >> AFP. > > #define AFP_MACHINETYPE_LEN 15 > > ------------------------------------------------------- > #define AFP_LOGINMESG_LEN > > Apple Filing Protocol Reference > Page 100 > >> The usual size of any of these messages is 200 bytes including >> the length byte (a Str199). >> AFP 3.x clients can request that the server send longer attention >> messages by setting the attention quantum size in the Option field >> of the DSOpenSession command (described in the document Apple Filing >> Protocol Client). > > #define AFP_LOGINMESG_LEN 199 or 200 ??? > > If UTF8 string is 200 over, this should be disregarded. > > or > > #define AFP_LOGINMESG_UTF8_LEN 65535 > > ------------------------------------------------------- > #define AFP_VOLPASS_LEN 8 > > maybe, ok. > > If DHX, 255. > > ------------------------------------------------------- > #define AFP_HOSTNAME_LEN 255 > > maybe, ok. > > ------------------------------------------------------- > #define AFP_ZONE_LEN 255 > > I don't know it. > > ------------------------------------------------------- > #define AFP_SERVER_ICON_LEN 256 > > ok. > > Apple Filing Protocol Programming Guide > Page 11 > >> A optional value of 256 bytes that is used to customize >> the appearance of server volumes on the Mac OS Desktop. >> It consists of a 32-by-32 bit (128 bytes) icon bitmap followed >> by a 32-by-32 bit (128 bytes) icon mask. >> The mask usually consists of the icon's outline filled with black >> (bits that are set). For more information about icons, >> refer to Inside Mac OS X. > > mask is 128. > > ------------------------------------------------------- > #define AFP_MAX_USERNAME_LEN > > Apple Filing Protocol Reference > Page 116 >> The name can be a string of up to 255 Macintosh Roman characters >> or an AFPName of up to 255 characters. > > #define AFP_MAX_USERNAME_LEN 255 > > ------------------------------------------------------- > #define AFP_MAX_PASSWORD_LEN > > maybe, 255 > > If cleartext or random number exchange, it is 8. > > ------------------------------------------------------- > >> There is a larger problem with filenames, I have a maximum filename >> length of 255 bytes, but in reality the length is up to 16 bits. In >> many places I preallocate the space for the filename, which is fine >> for a small number, but there are many places I don't want to >> allocate >> 64k. Changing this requires a lot of rework of anything that >> allocates space that references a filename. This is left for a >> later >> release. I expect you'll hit this too. > > I will explain it after tomorrow. > > -- > HAT > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Afpfs-ng-devel mailing list > Afp...@li... > https://lists.sourceforge.net/lists/listinfo/afpfs-ng-devel |
|
From: Alex d. <ale...@gm...> - 2008-07-16 19:00:46
|
HAT, Thanks for going through this. I'll make the appropriate changes in CVS soon. Most of them are pretty obvious. Some comments on some of the broken items: On 16-Jul-08, at 1:16 PM, HAT wrote: > > Your sources are not clear which bare string or Pascal string. > Pascal string include leading one byte. All these string lengths are for non-pascal strings. > ------------------------------------------------------- > #define AFP_LOGINMESG_LEN > > Apple Filing Protocol Reference > Page 100 > >> The usual size of any of these messages is 200 bytes including >> the length byte (a Str199). >> AFP 3.x clients can request that the server send longer attention >> messages by setting the attention quantum size in the Option field >> of the DSOpenSession command (described in the document Apple Filing >> Protocol Client). > > #define AFP_LOGINMESG_LEN 199 or 200 ??? > > If UTF8 string is 200 over, this should be disregarded. > > or > > #define AFP_LOGINMESG_UTF8_LEN 65535 Is there such a thing as a UTF8 login message? In reality, I've never seen a DSIAttention message that had anything in it (except for the login message). I think I'll leave this at 199. > ------------------------------------------------------- > #define AFP_VOLPASS_LEN 8 > > maybe, ok. > > If DHX, 255. Well, with DHX the volume password isn't really a volume password; it is done by authenticating with any username and a password. So I think this definition is correct . > ------------------------------------------------------- > #define AFP_MAX_PASSWORD_LEN > > maybe, 255 > > If cleartext or random number exchange, it is 8. Okay, that's a UAM-specific change. I'll delve into that code to see if that's respected. > > ------------------------------------------------------- > >> There is a larger problem with filenames, I have a maximum filename >> length of 255 bytes, but in reality the length is up to 16 bits. In >> many places I preallocate the space for the filename, which is fine >> for a small number, but there are many places I don't want to >> allocate >> 64k. Changing this requires a lot of rework of anything that >> allocates space that references a filename. This is left for a >> later >> release. I expect you'll hit this too. > > I will explain it after tomorrow. Yeah, this is a lot of work to redo this, and not the highest item on my list. It also needs to be done in an AFP version specific way. - Alex |
|
From: HAT <ha...@fa...> - 2008-07-16 17:16:18
|
Alex, >Yes, that doesn't seem right and I cannot remember where I got that >data from. I probably wrote that when I started this two years, and >in looking through the 3.1 docs it looks incorrect. I may have taken >this from netatalk. netatalk's volumename length is buggy. http://www003.upp.so-net.ne.jp/hat/netatalk/cjk.html >Is the solution just to increase the length of >AFP_VOLUME_NAME_UTF8_LEN to 255? > >It looks like AFP_VOLUME_NAME_LEN should be 27. > >Are there similiar problems with server name lengths? Your sources are not clear which bare string or Pascal string. Pascal string include leading one byte. ------------------------------------------------------- Apple Filing Protocol Programming Guide Page 16 >AFPNames are encoded in conformance to the Unicode standard (UTF-8), >which uses 16-bits to encode more than 65,000 characters. >To keep character coding simple and efficient, the Unicode Standard >assigns each character a unique numeric value and name. >To help when converting from UTF-8 to other script systems, >AFPNames begin with a four-byte text encoding hint that specifies >the script that was originally used to compose the name. >The text encoding hint is followed by a two-byte length field >specifying the length of the UTF-8 encoded name that follows. ------------------------------------------------------- #define AFP_SERVER_NAME_LEN Apple Filing Protocol Programming Guide Page 11 > A string in Pascal format of up to 32 characters. A leading-octet of Pascal string is length. #define AFP_SERVER_NAME_LEN 31 ------------------------------------------------------- #define AFP_SERVER_NAME_UTF8_LEN Apple Filing Protocol Reference Page 97 >UTF-8ServerName (AFPName) >AFPName containing the UTF-8-encoded name of the server. #define AFP_SERVER_NAME_UTF8_LEN 65535 This is not realistic. If UTF-8ServerName is 255 over, this volume should be disregarded. #define AFP_SERVER_NAME_UTF8_LEN 255 ------------------------------------------------------- #define AFP_VOLUME_NAME_LEN Apple Filing Protocol Reference Page 101 >For AFP 2.x, this command returns volume names in ANSI format >with a maximum length of 27 bytes. #define AFP_VOLUME_NAME_LEN 27 Maybe, the classic client has length of 31 bytes for volumename. 4 bytes have been reserved for suffix so that the same volumename may exist. 31 - 4 = 27 ------------------------------------------------------- #define AFP_VOLUME_NAME_UTF8_LEN Apple Filing Protocol Reference Page 101 >For AFP 3.x, this command returns volume names in UTF-8 format >with a one byte length byte specifying any length up to 255. >Note that the Finder limits setting volume names to no more than >27 characters. #define AFP_VOLUME_NAME_UTF8_LEN 255 Do not confuse "character" with "byte". Generally, One Latin character is 2 bytes as UTF8. One CJK character is 3 bytes as UTF8. 27 CJK characters are 81 bytes. If character is decomposed, it is more complex. ------------------------------------------------------- #define AFP_SIGNATURE_LEN 16 ok. ------------------------------------------------------- #define AFP_MACHINETYPE_LEN Apple Filing Protocol Programming Guide Page 11 >A string in Pascal format of up to 16 characters that describes >the file server's hardware and software but has no significance to AFP. #define AFP_MACHINETYPE_LEN 15 ------------------------------------------------------- #define AFP_LOGINMESG_LEN Apple Filing Protocol Reference Page 100 >The usual size of any of these messages is 200 bytes including >the length byte (a Str199). >AFP 3.x clients can request that the server send longer attention >messages by setting the attention quantum size in the Option field >of the DSOpenSession command (described in the document Apple Filing >Protocol Client). #define AFP_LOGINMESG_LEN 199 or 200 ??? If UTF8 string is 200 over, this should be disregarded. or #define AFP_LOGINMESG_UTF8_LEN 65535 ------------------------------------------------------- #define AFP_VOLPASS_LEN 8 maybe, ok. If DHX, 255. ------------------------------------------------------- #define AFP_HOSTNAME_LEN 255 maybe, ok. ------------------------------------------------------- #define AFP_ZONE_LEN 255 I don't know it. ------------------------------------------------------- #define AFP_SERVER_ICON_LEN 256 ok. Apple Filing Protocol Programming Guide Page 11 >A optional value of 256 bytes that is used to customize >the appearance of server volumes on the Mac OS Desktop. >It consists of a 32-by-32 bit (128 bytes) icon bitmap followed >by a 32-by-32 bit (128 bytes) icon mask. >The mask usually consists of the icon's outline filled with black >(bits that are set). For more information about icons, >refer to Inside Mac OS X. mask is 128. ------------------------------------------------------- #define AFP_MAX_USERNAME_LEN Apple Filing Protocol Reference Page 116 >The name can be a string of up to 255 Macintosh Roman characters >or an AFPName of up to 255 characters. #define AFP_MAX_USERNAME_LEN 255 ------------------------------------------------------- #define AFP_MAX_PASSWORD_LEN maybe, 255 If cleartext or random number exchange, it is 8. ------------------------------------------------------- >There is a larger problem with filenames, I have a maximum filename >length of 255 bytes, but in reality the length is up to 16 bits. In >many places I preallocate the space for the filename, which is fine >for a small number, but there are many places I don't want to allocate >64k. Changing this requires a lot of rework of anything that >allocates space that references a filename. This is left for a later >release. I expect you'll hit this too. I will explain it after tomorrow. -- HAT |
|
From: Alex d. <ale...@gm...> - 2008-07-16 14:08:55
|
HAT, Yes, that doesn't seem right and I cannot remember where I got that data from. I probably wrote that when I started this two years, and in looking through the 3.1 docs it looks incorrect. I may have taken this from netatalk. Is the solution just to increase the length of AFP_VOLUME_NAME_UTF8_LEN to 255? It looks like AFP_VOLUME_NAME_LEN should be 27. Are there similiar problems with server name lengths? I actually use the machine type to detect the server type, which is useful for: - compensating for broken servers, particularly netatalk but also the Apple extreme - displaying logos in GUIs when browsing for servers There is a larger problem with filenames, I have a maximum filename length of 255 bytes, but in reality the length is up to 16 bits. In many places I preallocate the space for the filename, which is fine for a small number, but there are many places I don't want to allocate 64k. Changing this requires a lot of rework of anything that allocates space that references a filename. This is left for a later release. I expect you'll hit this too. - Alex On 16-Jul-08, at 9:28 AM, HAT wrote: > Alex, > > Have you already noticed a problem of volumename length? > > If volumename is non-ASCII, UTF8 string is very long. > Actually, I cannot mount two of three volumes on Mac OS X 10.5.4. > This problem is fatal. > > In include/afp_protocol.h, > > #define AFP_VOLUME_NAME_LEN 33 > > For AFP2.x, this command returns volume names in ANSI format with a > maximum length of 27 bytes. > > > #define AFP_VOLUME_NAME_UTF8_LEN 33 > > For AFP3.x, this command returns volume names in UTF-8 format with a > one > byte length byte specifying any length up to 255. Note that the Finder > limits setting volume names to no more than 27 characters. > > #define AFP_MACHINETYPE_LEN 33 > > A string in Pascal format of up to 16 characters that describes the > file > servers hardware and software but has no significance to AFP. > > > If you do not know it, I report after examining it a little more. > > -- > HAT > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Afpfs-ng-devel mailing list > Afp...@li... > https://lists.sourceforge.net/lists/listinfo/afpfs-ng-devel |
|
From: HAT <ha...@fa...> - 2008-07-16 13:29:16
|
Alex, Have you already noticed a problem of volumename length? If volumename is non-ASCII, UTF8 string is very long. Actually, I cannot mount two of three volumes on Mac OS X 10.5.4. This problem is fatal. In include/afp_protocol.h, #define AFP_VOLUME_NAME_LEN 33 For AFP2.x, this command returns volume names in ANSI format with a maximum length of 27 bytes. #define AFP_VOLUME_NAME_UTF8_LEN 33 For AFP3.x, this command returns volume names in UTF-8 format with a one byte length byte specifying any length up to 255. Note that the Finder limits setting volume names to no more than 27 characters. #define AFP_MACHINETYPE_LEN 33 A string in Pascal format of up to 16 characters that describes the file servers hardware and software but has no significance to AFP. If you do not know it, I report after examining it a little more. -- HAT |
|
From: Alex d. <ale...@gm...> - 2008-07-14 02:15:23
|
I have some progress to show for the time investment in getting afpfs- ng integration with KDE. You can see some very early screenshots at: https://sourceforge.net/project/screenshots.php?group_id=179882 It shows konqueror accessing files over AFP using a new kioslave. It also shows connection dialog boxes for netatalk, an Airport Extreme and a Mac. This will be rolled into afpfs-ng 0.9, probably a few months away. Please do not expect to have any results from what's in CVS today, I promise you that you will have no success. There are also many features missing (like retrieving files). - Alex |
|
From: Alex d. <ale...@gm...> - 2008-06-19 13:39:26
|
On 19-Jun-08, at 7:48 AM, <ra...@rs...> <ra...@rs...> wrote: > > > On Tue, 17 Jun 2008 09:07:10 -0400, Alex deVries <ale...@gm... > > > wrote: >> >> Hm, I couldn't reproduce this easily. > > I can: on one machine. I couldn't on another... ?? > So I tried to attach gdb on the machine where it cored and ran into a > gdb/linux bug, where gdb can't read /proc/*/status for multithreaded > processes that effected some linux kernel. Yes, gdb is odd that way. Not trapping on signals is also required, so I use: handle SIGHUP SIGUSR2 SIGPIPE noprint - A |
|
From: Alex d. <ale...@gm...> - 2008-06-19 13:00:23
|
Applied to my internal 0.9 tree, it'll make its way into CVS over time... Thanks! - A On 19-Jun-08, at 7:48 AM, <ra...@rs...> <ra...@rs...> wrote: > > > On Tue, 17 Jun 2008 09:07:10 -0400, Alex deVries <ale...@gm... > > > wrote: >> >> Hm, I couldn't reproduce this easily. > > I can: on one machine. I couldn't on another... ?? > So I tried to attach gdb on the machine where it cored and ran into a > gdb/linux bug, where gdb can't read /proc/*/status for multithreaded > processes that effected some linux kernel. > > After digging around I found that the machine where status completed > succesfully showed the server signature as: > "50ff57ff50ff57ff50ff57ff50ff57ffffffe6" > > But it _is_: > "50f857e650f857e650f857e650f857e6" > > So obviously at least the signate printing code is malfunctioning and > overwrting it's statically allocated buffer on the stack. A look at > the > signature printing function revealed that the format string was wrong. > > Patch attached. > > Thanks again for afpfs-ng, it is a tremendous help while debugging > netatalk. > > Regards, > -Ralph > > <patch.txt> |
|
From: <ra...@rs...> - 2008-06-19 12:16:23
|
On Thu, 19 Jun 2008 13:48:53 +0200, <ra...@rs...> wrote: > Patch attached. Yikes! File order was reversed. Corrected (hopefully) patch attached. -Ralph |
|
From: <ra...@rs...> - 2008-06-19 11:48:58
|
On Tue, 17 Jun 2008 09:07:10 -0400, Alex deVries <ale...@gm...> wrote: > > Hm, I couldn't reproduce this easily. I can: on one machine. I couldn't on another... ?? So I tried to attach gdb on the machine where it cored and ran into a gdb/linux bug, where gdb can't read /proc/*/status for multithreaded processes that effected some linux kernel. After digging around I found that the machine where status completed succesfully showed the server signature as: "50ff57ff50ff57ff50ff57ff50ff57ffffffe6" But it _is_: "50f857e650f857e650f857e650f857e6" So obviously at least the signate printing code is malfunctioning and overwrting it's statically allocated buffer on the stack. A look at the signature printing function revealed that the format string was wrong. Patch attached. Thanks again for afpfs-ng, it is a tremendous help while debugging netatalk. Regards, -Ralph |
1 message has been excluded from this view by a project administrator.
