Re: FPSyncDir patch

Am 30.04.2008 um 00:35 schrieb didier:
> Le mardi 29 avril 2008 à 22:34 +0200, Ralph Böhme a écrit :
>> Didier,
>>
>> Am 25.04.2008 um 22:29 schrieb didier:
>>> Netatalk HEAD can use the 'classic' .AppleDouble/foo, ._foo or a  
>>> NTFS
>>> compatible layout  (with a patched samba 3, it was done because
>>> there's
>>> Windows press workflow softwares which expect this layout on SMB
>>> mounted
>>> volumes).
>>
>> can you please elaborate the Windows press workflow part. Which
>> software?
> I don't remember, that's old, maybe rampage or it was another issue.
>> Which patches?
> There's a patch for Samba in cvs HEAD contrib/patches but it's badly
> outdate, samba 3.0.5... It adds ADS support to Samba for CIFS clients
> and cvs HEAD understands adouble:sfm

There's the same(?) patch for Samba 3.0.20a in contrib/patches, isn't  
it?

>
>> Which layout?
> it uses
> .Adouble/foo/Afp_AfpInfo
> .Adouble/foo/Afp_Resource

Small patch to fix large file support cross compile issue

Hi,

I noticed an issue with autoconf checking for large file support (LFS)  
and failing because the environment was cross. The attached patch  
fixes this issue so that LFS will be true when the previous tests are  
fine.

Regards,
Bolke

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Netatalk-devel mailing list
Netatalk-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-devel

FPSyncFork progress

Hi,

I wanted to give you an update on the fpsyncfork patch. The reason for  
this patch for me is to get my Lacie Ethernet Big Disk working as time  
machine supported, hence the need to cross compile for (and thus the  
previous patch - another one is needed as well but is more obvious).

So I actually got it working on this small nas and I am happy to say  
that it is now recognized as time machine capable. However working  
from my previous patch (I haven't been able to move it to the  
suggested locations just yet) I am running into an issue which I do  
not quite understand right away. When running a timemachine backup the  
following happens:

May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:  
of_find(34) could not locate fork
May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:  
of_find(35) could not locate fork
May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:  
of_find(37) could not locate fork

Well that's it, timemachine continues happily (even though  
AFP_ERRPARAM is returned), but as it seems something is wrong and I  
don't know why . Someone else more familiar with the protocol could  
shed some light on this?

Furthermore, I have difficulty creating the 'proper' integration for  
these patches (fpsyncfork). My progress:

1) Only on linux is is necessary to traverse the directory if a fsync  

Re: Small patch to fix large file support cross compile issue

Hi,
> Hi,
> 
> I noticed an issue with autoconf checking for large file support (LFS)  
> and failing because the environment was cross. The attached patch  
> fixes this issue so that LFS will be true when the previous tests are  
> fine.
> 
Commit, thanks

Didier

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: FPSyncFork progress

Hi,
Le samedi 03 mai 2008 à 13:06 +0200, Bolke de Bruin a écrit :
> Hi,
> 
> I wanted to give you an update on the fpsyncfork patch. The reason for  
> this patch for me is to get my Lacie Ethernet Big Disk working as time  
> machine supported, hence the need to cross compile for (and thus the  
> previous patch - another one is needed as well but is more obvious).
> 

> following happens:
> 
> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:  
> of_find(34) could not locate fork
> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:  
> of_find(35) could not locate fork
> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:  
> of_find(37) could not locate fork
> 
> Well that's it, timemachine continues happily (even though  
> AFP_ERRPARAM is returned), but as it seems something is wrong and I  
> don't know why . Someone else more familiar with the protocol could  
> shed some light on this?
> 
- Difficult to tell, most of the time it's a client bug, ie they still
use already closed fork numbers. It could be a netatalk bug though :(

- If it's reproducible you can try to look with wireshark which open
files, if any, these fork numbers were associated with. You can also
look at the number of open forks when these bad numbers are used.

Re: FPSyncFork progress

Thanks. I'll have a further look at it. For now it seems a netatalk  
bug (or maybe even in my function) as it only happens with timemachine  
and the number increment by one everytime.

Op 6 mei 2008, om 19:13 heeft didier het volgende geschreven:

> Hi,
> Le samedi 03 mai 2008 à 13:06 +0200, Bolke de Bruin a écrit :
>> Hi,
>>
>> I wanted to give you an update on the fpsyncfork patch. The reason  
>> for
>> this patch for me is to get my Lacie Ethernet Big Disk working as  
>> time
>> machine supported, hence the need to cross compile for (and thus the
>> previous patch - another one is needed as well but is more obvious).
>>
>
>> following happens:
>>
>> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:
>> of_find(34) could not locate fork
>> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:
>> of_find(35) could not locate fork
>> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:
>> of_find(37) could not locate fork
>>
>> Well that's it, timemachine continues happily (even though
>> AFP_ERRPARAM is returned), but as it seems something is wrong and I
>> don't know why . Someone else more familiar with the protocol  

Re: FPSyncFork progress

brrr:

if (NULL == ( ofork == of_find( ofrefnum )) ) {

that's nog going to work of course :S.

BTW: Didier, would you accept the the afp_syncdir patch if provided  
separately?

Cheers,
Bolke.

Op 6 mei 2008, om 19:13 heeft didier het volgende geschreven:

> Hi,
> Le samedi 03 mai 2008 à 13:06 +0200, Bolke de Bruin a écrit :
>> Hi,
>>
>> I wanted to give you an update on the fpsyncfork patch. The reason  
>> for
>> this patch for me is to get my Lacie Ethernet Big Disk working as  
>> time
>> machine supported, hence the need to cross compile for (and thus the
>> previous patch - another one is needed as well but is more obvious).
>>
>
>> following happens:
>>
>> May  3 10:04:39 (none) daemon.err afpd[2430]: afpd_syncfork:
>> of_find(34) could not locate fork

Re: FPSyncFork progress

Hi,
Le jeudi 08 mai 2008 à 20:37 +0200, Bolke de Bruin a écrit :
> brrr:
> 
> if (NULL == ( ofork == of_find( ofrefnum )) ) {
> 
> that's nog going to work of course :S.
> 
> BTW: Didier, would you accept the the afp_syncdir patch if provided  
> separately?
Of course 

Didier

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Time Machine / Time Capsule Success! (no afp_fsyncfork yet)

Hi,

I just wanted to let you know that I have now a fully working
timecapsule replacement (meaning accepted by OSX). To also have these
shiny new feature follow the steps below.

1) Make sure you have applied at least the afp_fsyncdir patch to
netatalk (and check if it works, it still needs to be updated). This
step makes the volume recognized by TimeMachine.

2) To have the nice "airport disk feature" in Finder (or auto
detection of supported volumes) it is necessary to have a mdns daemon
which supports multiline TXT fields. Avahi works, I also tried mDNS
but I could not get it to recognize multiple lines.

the first record exists of "sys=waMA=<YOUR:ETHERNET:ADDRESS:HERE>"
the second record is "dk2=adVF=0x83,adVN=<AVOLUMENAMEFORBACKUP>,adVU=<A-UUID>"

(dk2 could be different, I havent tracked that down yet)

for example my adisk.service for Avahi looks like this:

<service-group>

  <name replace-wildcards="yes">TimeCapsule</name>

  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>

AFP proxy

Hello all,

I'm trying to setup an afp proxy, using afpd. My afpd.conf file contains
only the following line:

  - -transall -uamlist uams_clrtxt.so,uams_dhx.so -nosavepassword -proxy

afpd doesn't start with this configuration and the syslog contains the
following output

May 14 15:39:40 host2148 afpd[2771]: main: atp_open: Address family not
supported by protocol
May 14 15:39:40 host2148 afpd[2771]: uam: uams_clrtxt.so loaded
May 14 15:39:40 host2148 afpd[2771]: uam: uam not found (status=-1)
May 14 15:39:40 host2148 afpd[2771]: main: no servers configured: No
such file or directory

I believe that the following line is why afpd fails to start...

Does anyone know what server details are missing from the configuration?

Thanks in advance for any help,

John.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/