headers
Philip Edelbrock | 1 May 2004 01:08
Picon
Favicon

Re: File Compatibility

Impressive list, but they seem to be irrelevent or applying to old 
software/OS's.  See comments below.

Matthew Keller wrote:

>According to Apple: 
>
>~ Type/creator flags (resource forks) don't work on UFS:
>http://docs.info.apple.com/article.html?artnum=25316
>
>  
>
*"Note*: This document applies to Mac OS X 10.2.8 or earlier." 'nuf said

>~ Keynote can't find its themes unless the startupdisk is HFS+:
>http://docs.info.apple.com/article.html?artnum=61887
>
>  
>
Affects Keynote 1.0 (I don't have Keynote, but a more receint version 
probably works under UFS?)

>~ AirPort wouldn't work with pre 10.1 systems installed on UFS:
>http://docs.info.apple.com/article.html?artnum=106252
>
>  
>
"Pre 10.1" is pretty old...  I've been using Airport Extreme quite 
extensively since I bought my laptop.  Works fine.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Keller | 2 May 2004 05:22

Re: File Compatibility

On Fri, 2004-04-30 at 19:08, Philip Edelbrock wrote:
> Again, I don't know if you don't believe me (or if I care at this 
> point), but my laptop really does boot, run, and work (resource forks, 
> icons, apps and all) just fine on my UFS formatted laptop.  If you're 
> trying to convince me that my laptop isn't working, you'll have to do 
> more than list a bunch of old articles! ;')

I'm glad Apple's improved their support for non-HFS+ filesystems. I'm
glad your laptop boots/works with UFS. The list shown was honest about
the age of the articles- Some are current, some are older- Those are
just a few from the "UFS files" in Apple's support library that I had
bookmarked as I (back when I used OSX) or someone else whom I've worked
with ran into problems with. What the list does show, in my opinion, is
that "even Apple" [has had/is having] oodles and oodles of problems with
non-HFS+ filesystems.

I'm sorry I don't seem to be able to articulate the difficulty of
supporting AFP volumes on non-HFS+ filesystems, and that the Netatalk
method of .AppleDouble folders is actually the most scalable way to
properly handle multiple-fork files. ._ files aren't a very good
solution for all filesystems, whether I can properly articulate it or
not. 

--

-- 
Matthew Keller
signat-url: http://mattwork.potsdam.edu/signat-url/
"No one ever says, 'I can't read that ASCII E-mail you sent me.'"
Permalink | Reply | 0 comments |
headers
Harald Wagener | 3 May 2004 11:13

A Big Thank You for five star support

Dear list,
I just want to thank the netatalk developers, especially Thomas and 
Didier for their unparalleled support this weekend.

Our new servers sporting netatalk 2.0b+acl patches is working, and 
everything is working right now with 50 users logged into each server. 
If problems come up, I will certainly come back here (-;

I had the opportunity to test uniconv, which did it's job. Only thing 
it does not seem to do right is the dry run (-n): It does not recurse 
beyond the top level directories if it has to recreate the cnid data 
base, possibly because one does not exist.

I will rebuild the netatalk debs soonish (they should contain uniconv, 
which they don't at the moment), and post relevant diffs on 
netatalk-devel.

A word of warning: In our case, copying the data from an 1.x 
installation to 2.x did not work out using either finder copy or ditto 
because the clients experienced kernel panics. Be sure to test this 
thoroughly. It may be related to us not using the latest 1.6.4, but 
still having 1.6.2 installed, bugs in the client's afp implementation, 
timing problems, bugs in the netatalk series. Only thing I can say that 
the servers did not log anything suspicious beyond 'unexpected end of 
stream'

Oh, and Finder Copy and ditto both don't seem to cope with directory 
names containing spaces too well. We resolved the issue by copying the 
data directly from client to client using conventional unix methods 
(star via ssh), recreating the cnid databases (in the process of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Wagener | 3 May 2004 16:04

Access Rights Problem with netatalk 2.0b(+acl patches)

Hello,
our new fileservers are happily serving files.

One problem is new, though: Users cannot copy directories they have 
only reading rights on because the Mac sets them read-only on the 
target directory as well. Example: We have a directory our dtp unit 
stores finalized data in so the creative people can find that data for 
later work. This directory is rwxrwxr-x, owned by the head of dtp and 
group dtp:

fileserver1:/mnt/files/service# ls -lad DTP
drwxrwxr-x   12 xxxxxxxx   dtp          4096 May  1 06:53 DTP
fileserver1:/mnt/files/service#

DTP contains, amongst others, a directory called 'atalk 2.0'. Inside is 
a file 'test.txt' and a directory 'testfolder', which in turn contains 
'test2.txt'. Access rights are as follows:

fileserver1:/mnt/files/service/DTP# ls -lad atalk\ 2.0/
drwxrwxr-x    3 bmeyer   dtp            38 May  3 15:55 atalk 2.0/
fileserver1:/mnt/files/service/DTP#

If I copy that to my Desktop, I get a structure with the following info:

Wagener-Harald:~/Desktop hollow$ ls -lad atalk\ 2.0/
dr-xr-xr-x  4 hollow  hollow  136  3 May 15:55 atalk 2.0/
Wagener-Harald:~/Desktop hollow$

Now, people can't work with their freshly copied data )-: Additionally, 
if You have more files and directories, only the directory structure
(Continue reading)

Permalink | Reply | 8 comments |
headers
Harald Wagener | 3 May 2004 16:04

A Big Thank You for five star support (and one problem)


Dear list,
I just want to thank the netatalk developers, especially Thomas and 
Didier for their unparalleled support this weekend.

Our new servers sporting netatalk 2.0b+acl patches is working now with 
50 users logged into each server. One problem has cropped up, see my 
other mail.

I had the opportunity to test uniconv, which did it's job. Only thing 
it does not seem to do right is the dry run (-n): It does not recurse 
beyond the top level directories if it has to recreate the cnid data 
base, possibly because one does not exist.

I will rebuild the netatalk debs soonish (they should contain uniconv, 
which they don't at the moment), and post relevant diffs on 
netatalk-devel.

A word of warning: In our case, copying the data from an 1.x 
installation to 2.x did not work out using either finder copy or ditto 
because the clients experienced kernel panics. Be sure to test this 
thoroughly. It may be related to us not using the latest 1.6.4, but 
still having 1.6.2 installed, bugs in the client's afp implementation, 
timing problems, bugs in the netatalk series. Only thing I can say that 
the servers did not log anything suspicious beyond 'unexpected end of 
stream'

Oh, and Finder Copy and ditto both don't seem to cope with directory 
names containing spaces too well. We resolved the issue by copying the 
data directly from client to client using conventional unix methods
(Continue reading)

Permalink | Reply | 0 comments |
headers
Libor Vanek | 4 May 2004 03:39
Picon

Compiling with custom DB4 fails?

Hi,
I'm using RedHat 9.0. I've downloaded BDB4 4.1.25 and 4.2.52. I've compiled both (see lower) with
"configure --prefix=/usr/local/db4"

I've tested 2.0-beta1 and "current CVS" from: http://netatalk.agentur-fineline.de/packages/current-afp3-dev.tar.gz

Options used:
./configure \
        --prefix=/usr/local/netatalk \
        --libexec=/usr/libexec/netatalk \
        --with-config-dir=/etc/atalk \
        --with-pkgconfdir=/etc/atalk \
        --with-uams-path=/etc/atalk/uams \
        --with-message-dir=/etc/atalk/msg \
        --enable-redhat \
        --with-ssl \
        --enable-sendfile \
        --with-pam \
        --with-cracklib \
        --with-shadow \
        --with-tcp-wrappers \
        --with-cnid-default-backend=cdb \
        --with-cnid-cdb-backend \
        --with-cnid-dbd-txn \
        --with-cnid-dbd-backend \
        --with-bdb=/usr/local/db4

Error message during configure:
checking default DID scheme... cdb
checking whether default CNID scheme has been activated... yes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Fernhomberg | 4 May 2004 08:52
Picon

RE: Access Rights Problem with netatalk 2.0b(+acl patches)

> Hello,
> our new fileservers are happily serving files.
> 
> One problem is new, though: Users cannot copy directories they have 
> only reading rights on because the Mac sets them read-only on the 
> target directory as well. Example: We have a directory our dtp unit 
> stores finalized data in so the creative people can find that 
> data for 
> later work. This directory is rwxrwxr-x, owned by the head of dtp and 
> group dtp:
> 
> fileserver1:/mnt/files/service# ls -lad DTP
> drwxrwxr-x   12 xxxxxxxx   dtp          4096 May  1 06:53 DTP
> fileserver1:/mnt/files/service#
> 
> DTP contains, amongst others, a directory called 'atalk 2.0'. 
> Inside is 
> a file 'test.txt' and a directory 'testfolder', which in turn 
> contains 
> 'test2.txt'. Access rights are as follows:
> 
> fileserver1:/mnt/files/service/DTP# ls -lad atalk\ 2.0/
> drwxrwxr-x    3 bmeyer   dtp            38 May  3 15:55 atalk 2.0/
> fileserver1:/mnt/files/service/DTP#
> 
> If I copy that to my Desktop, I get a structure with the 
> following info:
> 
> Wagener-Harald:~/Desktop hollow$ ls -lad atalk\ 2.0/
> dr-xr-xr-x  4 hollow  hollow  136  3 May 15:55 atalk 2.0/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Wortelboer | 4 May 2004 09:06
Picon
Picon
Favicon

Re: Access Rights Problem with netatalk 2.0b(+acl patches)

The system is creating stuff xor with permissions.

If you greate a file in your own folder than the file permissions
are xor'd with the folder permissions

depening on umask lets say your umask = 022 and directory/folder
is 751 (drwxr-x--x).

Then files created in the folder get

0644 & 751 = 0640 (-rw-r-----), so not readable for other.

In de case below, the xxxxxxxx:dtp permissions on DTP for
hollow:hollow are r-x because hollow is not xxxxxxxx and group
not dtp.

So files created ares xor'd with 5, so you get

777 & 555 => 555 = dr-xr-xr-x.

Jan.

On Mon, May 03, 2004 at 04:04:47PM +0200, Harald Wagener wrote:
> 
> Hello,
> our new fileservers are happily serving files.
> 
> One problem is new, though: Users cannot copy directories they have 
> only reading rights on because the Mac sets them read-only on the 
> target directory as well. Example: We have a directory our dtp unit
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harald Wagener | 4 May 2004 11:56

Re: Access Rights Problem with netatalk 2.0b(+acl patches)

Am 04.05.2004 um 09:06 schrieb Jan Wortelboer:

> The system is creating stuff xor with permissions.
>
> If you create a file in your own folder then the file permissions
> are xor'd with the folder permissions
>
> depening on umask lets say your umask = 022 and directory/folder
> is 751 (drwxr-x--x).
>
> Then files created in the folder get
>
> 0644 & 751 = 0640 (-rw-r-----), so not readable for other.
>
> In the case below, the xxxxxxxx:dtp permissions on DTP for
> hollow:hollow are r-x because hollow is not xxxxxxxx and group
> not dtp.
>
> So files created are xor'd with 5, so you get
>
> 777 & 555 => 555 = dr-xr-xr-x.
>
> Jan.
>

This is all true, but I don't think this is right or expected behavior. 
I would expect to be able to completely copy off a directory structure 
i have reading rights for. I could live with the client setting the 
rights to whatever it thinks are right after completely copying and 
writing all the data I have access for.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel E. Lautenschleger | 4 May 2004 20:56
Picon

--with-bdb=? for Debian

Trying to build Beta1 on a Debian "testing" machine. /usr/lib has the following
in it:

libdb-3.2.so -> libdb3.so.3.0.2
lrwxrwxrwx    1 root     root           15 Apr 28 10:23 libdb-3.so ->
libdb3.so.3.0.2
-rw-r--r--    1 root     root       678256 Sep 14  2003 libdb-4.0.so
-rw-r--r--    1 root     root       789512 Mar 17 10:33 libdb-4.1.so
-rw-r--r--    1 root     root       876584 Mar 22 17:36 libdb-4.2.so
lrwxrwxrwx    1 root     root           15 Apr 28 10:23 libdb3.so.3 ->
libdb3.so.3.0.2
-rw-r--r--    1 root     root       642472 Jun 16  2003 libdb3.so.3.0.2

Curious why --with-bdb=/usr/lib won't work. Do I need to make a symlink and call
it something else?

Thanks.
-Dan

--------

 .*.
  V
(   )
(   )
^^_^^

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
(Continue reading)

Permalink | Reply | 8 comments |

Gmane