Frank Lahm | 1 Mar 07:02 2010

Re: test426

2010/2/28 didier <dgautheron <at> magic.fr>:
> Hi,
> Le samedi 27 février 2010 à 10:47 +0100, Frank Lahm a écrit :
>> Hi Didier,
>>
>> test426 fails in FPOpenFork(symlink) because it calls with OPENACC_WR
>> which we deny in ad_open.
>> I'm not patching this myself because I'm not sure why you possibly
>> wanted to achieve here.
>
> Nothing but it's not an error with Mac OSX, move it to failed?

No, I guess afpd (ie ad_open) is right in preventing OPENACC_WR for
symlinks. I've checked another nettrace and indeed, nomatter what you
do, the client itself _never_ call FPOpen for a symlink with
OPENACC_WR.
So in the end the test should have to be modified:
- test that server returns AFPERR_PARAM for FPOpen with OPENACC_WR

Cheers, Frank

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Netatalk-devel mailing list
Netatalk-devel <at> lists.sourceforge.net
(Continue reading)

Frank Lahm | 1 Mar 07:11 2010

Re: [Netatalk-cvs] test-suite/test T2_FPOpenFork.c, 1.12, 1.13

2010/3/1 didier gautheron <didg <at> users.sourceforge.net>:
> Update of /cvsroot/netatalk/test-suite/test
> In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv20824
>
> Modified Files:
>        T2_FPOpenFork.c
> Log Message:
> test411: opening read-only a file without adouble resource fork doesn't create one
>
> Index: T2_FPOpenFork.c
> ===================================================================
> RCS file: /cvsroot/netatalk/test-suite/test/T2_FPOpenFork.c,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -C2 -d -r1.12 -r1.13
> *** T2_FPOpenFork.c     9 Feb 2010 08:57:43 -0000       1.12
> --- T2_FPOpenFork.c     28 Feb 2010 23:20:22 -0000      1.13
> ***************
> *** 823,826 ****
> --- 823,884 ----
>
>  /* ------------------------- */
> + STATIC void test411()
> + {
> + char *name = "t411 folder";
> + char *file = "t411 file.txt";
> + u_int16_t bitmap = 0;
> + int fork;
> + u_int16_t vol = VolID;
> + int dir;
(Continue reading)

Frank Lahm | 1 Mar 07:43 2010

Re: [Netatalk-cvs] netatalk/libatalk/util unix.c, 1.5, 1.6

2010/2/28 didier gautheron <didg <at> users.sourceforge.net>:
> Update of /cvsroot/netatalk/netatalk/libatalk/util
> In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv5300/libatalk/util
>
> Modified Files:
>        unix.c
> Log Message:
> previous commit 'lchdir: use chdir + getcwd' was only testing for symlink outside the volume's root
directory, hopefully this one is correct
>
> Index: unix.c
> ===================================================================
> RCS file: /cvsroot/netatalk/netatalk/libatalk/util/unix.c,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -C2 -d -r1.5 -r1.6
> *** unix.c      28 Feb 2010 17:02:49 -0000      1.5
> --- unix.c      28 Feb 2010 22:29:16 -0000      1.6
> ***************
> *** 37,41 ****
>  #include <atalk/afp.h>
>  #include <atalk/logger.h>
> - #include <atalk/volume.h>
>  #include <atalk/vfs.h>
>  #include <atalk/util.h>
> --- 37,40 ----
> ***************
> *** 65,72 ****
>   *  <at> returns 1 if a path element is a symlink, 0 otherwise, -1 on syserror
>   */
(Continue reading)

didier | 1 Mar 16:31 2010
Picon

Re: [Netatalk-cvs] netatalk/libatalk/util unix.c, 1.5, 1.6

Hi,
Le lundi 01 mars 2010 à 07:43 +0100, Frank Lahm a écrit :

> 
> Hm, this version now doesn't really do what's still in the spec for
> the function:
> 
>    " * Only chdirs to dir if it doesn't contain symlinks."
I have to update it.
> 
> That might be ok though, but it burdens the error handling on the
> callers _and_ the callers cwd is, well, changed. Shouldn't lchdir in
> case it detects a symlink try to chdir back? It therefor should
> open(".",O_RDONLY) before chdir to the requested path. And again, in
The pb is that we can chdir in a directory without read access and in
this case open(".",O_RDONLY) fail.

Create a folder rwx-wx--- and as a group member mount the volume, afpd
will chdir in it on client requests.

Switching to a known directory in lchdir is an option but we can't
guarantee that it will be able to switch back and there's the global
variable curdir to update.

Currently there's two users of lchdir, catsearch and movecwd.

On error catsearch doesn't care about the current directory.

I'm not sure that changing cwd to a directory which is not the requested
one in movecwd is a good idea, on the other hand the sentence:
(Continue reading)

didier | 1 Mar 21:35 2010
Picon

Re: [Netatalk-cvs] test-suite/test T2_FPOpenFork.c, 1.12, 1.13

Hi,
Le lundi 01 mars 2010 à 07:11 +0100, Frank Lahm a écrit :
> 2010/3/1 didier gautheron <didg <at> users.sourceforge.net>:
> > Update of /cvsroot/netatalk/test-suite/test
> > In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv20824
> >
> > Modified Files:
> >        T2_FPOpenFork.c
> > Log Message:
> > test411: opening read-only a file without adouble resource fork doesn't create one
> >
> > Index: T2_FPOpenFork.c
> > ===================================================================
> > RCS file: /cvsroot/netatalk/test-suite/test/T2_FPOpenFork.c,v
> > retrieving revision 1.12
> > retrieving revision 1.13
> > diff -C2 -d -r1.12 -r1.13
> > *** T2_FPOpenFork.c     9 Feb 2010 08:57:43 -0000       1.12
> > --- T2_FPOpenFork.c     28 Feb 2010 23:20:22 -0000      1.13
> > ***************
> > *** 823,826 ****
> > --- 823,884 ----
> >
> >  /* ------------------------- */
> > + STATIC void test411()
> > + {
> > + char *name = "t411 folder";
> > + char *file = "t411 file.txt";
> > + u_int16_t bitmap = 0;
> > + int fork;
(Continue reading)

Andrew Morgan | 1 Mar 21:40 2010

Re: Mediawiki

On Sun, 28 Feb 2010, Frank Lahm wrote:

> I've activated Mediawiki so we can evaluate it and see if we like it:
> <https://sourceforge.net/apps/mediawiki/netatalk/index.php?title=Main_Page>
>
> I've migrated some pages from the old wiki (eg parts of the FAQ) to
> it. After some struggling with the formatting syntax I now think it'll
> be quite ok.
>
> What do you guys think about it?

I'm always in favor of using standard tools provided by Sourceforge 
instead of tools we have to install and maintain ourselves.

 	Andy

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Frank Lahm | 2 Mar 07:21 2010

Re: Mediawiki

2010/3/1 Andrew Morgan <morgan <at> orst.edu>:
> On Sun, 28 Feb 2010, Frank Lahm wrote:
>
>> I've activated Mediawiki so we can evaluate it and see if we like it:
>>
>> <https://sourceforge.net/apps/mediawiki/netatalk/index.php?title=Main_Page>
>>
>> I've migrated some pages from the old wiki (eg parts of the FAQ) to
>> it. After some struggling with the formatting syntax I now think it'll
>> be quite ok.
>>
>> What do you guys think about it?
>
> I'm always in favor of using standard tools provided by Sourceforge instead
> of tools we have to install and maintain ourselves.

Ok.

Meanwhile I've completed the migration of all stil relevant content
from the old wiki to the new one. I've acticated a htaccess redirect
that redirects the [faq] link from the header navigation at
netatalk.sf.net to the new wiki. This so, until the static pages and a
new manual are online where I'd change [faq] for [wiki] linking
directly then of course. Any objections ?

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
(Continue reading)

Frank Lahm | 3 Mar 11:38 2010

Re: test426

2010/3/1 Frank Lahm <franklahm <at> googlemail.com>:
> 2010/2/28 didier <dgautheron <at> magic.fr>:
>> Hi,
>> Le samedi 27 février 2010 à 10:47 +0100, Frank Lahm a écrit :
>>> Hi Didier,
>>>
>>> test426 fails in FPOpenFork(symlink) because it calls with OPENACC_WR
>>> which we deny in ad_open.
>>> I'm not patching this myself because I'm not sure why you possibly
>>> wanted to achieve here.
>>
>> Nothing but it's not an error with Mac OSX, move it to failed?
>
> No, I guess afpd (ie ad_open) is right in preventing OPENACC_WR for
> symlinks. I've checked another nettrace and indeed, nomatter what you
> do, the client itself _never_ call FPOpen for a symlink with
> OPENACC_WR.
> So in the end the test should have to be modified:
> - test that server returns AFPERR_PARAM for FPOpen with OPENACC_WR

*ping*

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Netatalk-devel mailing list
(Continue reading)

AndrewL733 | 5 Mar 03:07 2010
Picon

Symlinks and Netatalk 2.1

Hello,

I have been using older versions of Netatalk (i.e., 2.0.3 and 2.0.4) for 
quite some time.  I just compiled 2.1 beta 1 and noticed that Linux file 
and directory symlinks are now conveyed to the Mac client as symlinks, 
versus in the past they just looked like regular files and folders.

My questions are:

1)  is there a run-time netatalk configuration option to get the OLD 
behavior?

2)  If not, can you point me to what code has to be removed from the 
current netatalk source so that host-side symlinks are just conveyed to 
the client as regular files and directories?    Has somebody already 
made a patch to modify the current source back to the old behavior?

Thanks in advance,
Andrew

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Frank Lahm | 5 Mar 07:09 2010

Re: Symlinks and Netatalk 2.1

2010/3/5 AndrewL733 <AndrewL733 <at> aol.com>:
> Hello,
>
> I have been using older versions of Netatalk (i.e., 2.0.3 and 2.0.4) for
> quite some time.  I just compiled 2.1 beta 1 and noticed that Linux file
> and directory symlinks are now conveyed to the Mac client as symlinks,
> versus in the past they just looked like regular files and folders.

What's the problem with it?

> My questions are:
>
> 1)  is there a run-time netatalk configuration option to get the OLD
> behavior?

No. Also not planned.

> 2)  If not, can you point me to what code has to be removed from the
> current netatalk source so that host-side symlinks are just conveyed to
> the client as regular files and directories?    Has somebody already
> made a patch to modify the current source back to the old behavior?

No. The code is not even finished. There are stll some necessary fixes
in the pipe.

Cheers, Frank

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
(Continue reading)


Gmane