Simon Bazley | 1 Sep 13:43 2002

Re: 1.5.5final?

I thought I had lifted the code for snprintf (or something else
that wasn't implemented on Tru64) so I could use it on the logger code.
Anyway I remember looking through a load of vsnprintf functions in a gnu
library at some point.  Do you think it would be kosher to just copy a
load of the gnu code from the standard c libraries and pop it in
libatalk/util, so the Tru64 chaps can have vsnprinf support (or is that
exactly what you're proposing)?

Simon

On Fri, 30 Aug 2002, Sebastian Rittau wrote:

> On Thu, Aug 29, 2002 at 09:36:09PM -0400, Joe Marcus Clarke wrote:
> > On Thu, 2002-08-29 at 19:43, Sebastian Rittau wrote:
>
> > > are there any *major* regressions in 1.5.5beta? If not, I will ask
> > > Andrew soon to move 1.5.5beta to SF as official 1.5.5.
> >
> > There is a Tru64 NFS quota issue which is fixed and checked into
> > stable.  There is also the issue of no snprintf() in Tru64 which will be
> > fixed soon (probably tomorrow).  I'd like to make sure those two things
> > go into 1.5.5.
>
> Ok, please notify me if you've committed the snprintf fix. I will then
> make a 1.5.5beta2 release.
>
>  - Sebastian
>
>
>
(Continue reading)

Sebastian Rittau | 1 Sep 18:34 2002
Picon

Re: 1.5.5final?

On Sun, Sep 01, 2002 at 12:43:33PM +0100, Simon Bazley <sibaz <at> sibaz.com> wrote:

> I thought I had lifted the code for snprintf (or something else
> that wasn't implemented on Tru64) so I could use it on the logger code.
> Anyway I remember looking through a load of vsnprintf functions in a gnu
> library at some point.  Do you think it would be kosher to just copy a
> load of the gnu code from the standard c libraries and pop it in
> libatalk/util, so the Tru64 chaps can have vsnprinf support (or is that
> exactly what you're proposing)?

I think it should be possible to take it from the GNU C Lib, since we're
not GPL'ed. The best thing to do was probably to create a static
"libcompat" which we link against and which will contain all features,
which we need but which don't exist on all our target platforms.

 - Sebastian

Sebastian Rittau | 1 Sep 19:05 2002
Picon

Netatalk 1.5.5 beta 2

Hi!

Netatalk 1.5.5 beta 2 is now available at
http://me.in-berlin.de/~jroger/netatalk/netatalk-1.5.5beta2.tar.gz
This version includes Tru64-fixes for NFS and vsnprintf().

Please test this version so that we can have a final 1.5.5 release, soon.

 - Sebastian

Joe Marcus Clarke | 1 Sep 20:10 2002

Re: 1.5.5final?

On Sun, 2002-09-01 at 12:34, Sebastian Rittau wrote:
> On Sun, Sep 01, 2002 at 12:43:33PM +0100, Simon Bazley <sibaz <at> sibaz.com> wrote:
> 
> > I thought I had lifted the code for snprintf (or something else
> > that wasn't implemented on Tru64) so I could use it on the logger code.
> > Anyway I remember looking through a load of vsnprintf functions in a gnu
> > library at some point.  Do you think it would be kosher to just copy a
> > load of the gnu code from the standard c libraries and pop it in
> > libatalk/util, so the Tru64 chaps can have vsnprinf support (or is that
> > exactly what you're proposing)?
> 
> I think it should be possible to take it from the GNU C Lib, since we're
> not GPL'ed. The best thing to do was probably to create a static
> "libcompat" which we link against and which will contain all features,
> which we need but which don't exist on all our target platforms.

I already added snprintf and vspnprintf to netatalk HEAD and stable. 
This was Burkhard's recent patch did.  Take a look at
libatalk/compat/snprintf.c.

Joe

> 
>  - Sebastian
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
(Continue reading)

Andre Schild | 2 Sep 15:08 2002
Picon

RE: Netatalk 1.5.5 beta 2

>Netatalk 1.5.5 beta 2 is now available at
>http://me.in-berlin.de/~jroger/netatalk/netatalk-1.5.5beta2.tar.gz
>This version includes Tru64-fixes for NFS and vsnprintf().
>
So far it compiles and runs fine under my test SuSE 8.0
Will put it one productive server this night.

André

Burkhard Schmidt | 2 Sep 15:14 2002
Picon

Re: Netatalk 1.5.5 beta 2

Am Sonntag, 01.09.02 um 19:05 Uhr schrieb Sebastian Rittau:

> Netatalk 1.5.5 beta 2 is now available at
> http://me.in-berlin.de/~jroger/netatalk/netatalk-1.5.5beta2.tar.gz
> This version includes Tru64-fixes for NFS and vsnprintf().

… and it compiles and installs "out of the box," without the need to 
apply any additional patches! Thank you, Joe and Sebastian.

Regards, Burkhard.

Simon Bazley | 2 Sep 17:48 2002

Re: Netatalk 1.5.5 beta 2

Burkhard,
            I tried replying to you personally, on bs <at> cpfs.mpg.de, and I
got a mail failure.  Can you email me an address that works.

Simon

Burkhard Schmidt wrote:

> Am Sonntag, 01.09.02 um 19:05 Uhr schrieb Sebastian Rittau:
>
> > Netatalk 1.5.5 beta 2 is now available at
> > http://me.in-berlin.de/~jroger/netatalk/netatalk-1.5.5beta2.tar.gz
> > This version includes Tru64-fixes for NFS and vsnprintf().
>
> … and it compiles and installs "out of the box," without the need to
> apply any additional patches! Thank you, Joe and Sebastian.
>
> Regards, Burkhard.
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Netatalk-devel mailing list
> Netatalk-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel

David Brownlee | 2 Sep 18:39 2002
Picon

Leaking filedescriptors with MacOS X clients

	I've noticed that a MacOS X client (probably running mozilla with
	the filestore on the server) seems either to be casuing afpd to leak
	filedescriptors, or just opening files and never closing:

	syslog reports:

12:49:06 wopr afpd[24102]: ASIP session:548(1) from 192.168.1.115:49200(2)
12:49:06 wopr afpd[24102]: dhx login: jamie
12:49:06 wopr afpd[24102]: login jamie (uid 1002, gid 100) AFP2.2
12:49:37 wopr afpd[24102]: afp_write: ad_write: Bad file descriptor
12:51:25 wopr afpd[24102]: afp_write: ad_write: Bad file descriptor
12:51:27 wopr afpd[24102]: afp_flushfork: of_find: Bad file descriptor
12:51:27 wopr afpd[24102]: afp_write: ad_write: Bad file descriptor
14:37:15 wopr afpd[24102]: afp_write: ad_write: Bad file descriptor
14:37:15 wopr afpd[24102]: afp_write: ad_write: Bad file descriptor
14:59:25 wopr afpd[24102]: of_alloc: maximum number of forks exceeded.

	and fstat -p:

USER     CMD          PID   FD MOUNT       INUM MODE         SZ|DV R/W
jamie    afpd       24102   wd /home     549607 drwxrwxr-x     512 r
jamie    afpd       24102    0 /home     548522 -rw-rw-r--  296034 rw
jamie    afpd       24102    1 /home     549004 -rw-rw-r--     589 rw
jamie    afpd       24102    2* internet stream tcp c212a294 192.168.1.3:548 <->
 192.168.1.115:49200
jamie    afpd       24102    3* unix dgram c21507c0 <-> c1e0c640
jamie    afpd       24102    4 /home     549456 -rw-rw-r--  135168 rw
jamie    afpd       24102    5 /home     549457 -rw-rw-r--     589 rw
jamie    afpd       24102    6 /home     549458 -rw-rw-r--   57856 rw
<repeat around another 240 similar lines>
(Continue reading)

Jennifer Choate | 3 Sep 22:03 2002
Picon
Picon

Please help Home Entertainment Companies with Survey - Win a DVR!

We thank you for just a moment of your time. NextResearch is inviting you to join a panel of consumer electronics users now being created to help manufacturers, network programmers, and entertainment companies shape their future offerings. In exchange for your willingness to participate, there will be prizes and incentives awarded. ALL CONTACT INFORMATION WILL BE HELD IN STRICTEST CONFIDENCE AND WE WILL NEVER TRY TO SELL YOU ANYTHING. You will be able to opt-out of the panel at any time.

Please click here http://65.19.137.17/nextresearch/nr.htm if you would like to participate in your first survey and earn a chance to win one of 25 new Digital Video Recorders being awarded in September! (You do not have to join the panel to participate in this survey.) This is a national market research program conducted with the highest ethical standards. Feel free to contact program director, Jennifer Choate at 901.491.4995 with any questions. To unsubscribe from this list, simply reply to this email to be removed from future invitations to participate.

Thank you again for your consideration,

NextResearch

(http://www.nextresearch.com)

Link to survey: http://65.19.137.17/nextresearch/nr.htm

Matthew Geier | 5 Sep 07:25 2002
Picon
Picon

Cnid DB corruption on Digital Unix

 1.5.5 with cnid on Digital Unix 4.0f is getting repeated cnid database
corruption.
 Unfortunatly other than the syslog messages I can't really debug it
further, ill be switching back to some other DID scheme.

Sep  5 14:11:26 plato afpd[20478]: cnid_lookup: txn_checkpoint:
DB_RUNRECOVERY:
Fatal error, run database recovery
Sep  5 14:11:26 plato afpd[20478]: cnid_add: Failed to begin
transaction: DB_RUNRECOVERY: Fatal error, run database recovery

 The only 'cure' seems to be to boot every one off the server, delete
the
.AppleDB directory and sit back and wait for it to happen again.

 When the database does go - the client workstations either show an
empty 
share (resulting in much panic on the users part) or their workstation
crashes.
 I'm not able to determine if this is OS version specific.

 It works fine in testing from a number of workstations in our 'support
centre'
and seems to work fine for a day or so with 'real' users, but sooner to
later
it blows up.

--
Matthew Geier			matthew <at> arts.usyd.edu.au
Arts IT Unit			+61 2 9351 4713
Sydney University


Gmane