Subject: Re: a faq on broken aliass (was Re: Fixed file ID's)
From: Robert B. Bell (rbell@tv.rsc.raytheon.com)
Date: Tue Feb 01 2000 - 15:11:13 EST
At 01:35 AM 1/18/00 -0800, a sun wrote:
> [another question on broken aliases and fixed file id's ...]
>
>if somebody could enter this as a faq, that would be great. there
>seems to be some confusion on why aliases don't work. here's the
>answer:
> 1) macos pre-8.6 used a path composed of fileid/directory id's
> to lookup aliases.
> 2) in afpd, file id's are fixed, but directory id's are
> variable.
>
>as a result, macos pre-8.6 will just fail with aliases that refer to
>files that are more than one directory level deep. with macos 8.6 or
>higher, the alias manager will attempt to resolve those by
>pathname. as long as a directory doesn't get assigned the same
>directory id as one in the alias, things should be all right. for
>files, this algorithm should be good enough as file id's are not
>likely to be duplicated on a system. for directory aliases, however,
>this can fail because directory ids can get re-assigned between
>connections.
>
>anyways, i'm going to stick in a workaround that should handle things
>until we get proper catalogue database support. currently, this is how
>file id's are assigned:
> 16 bits: device
> 16 bits: inode
>
>i'll change the id assignment to look like the following:
> 1 bit: directory/file identifier (set == it's a file)
> 13 bits: device
> 18 bits: inode
>
>18 bits allows for 262144 files on the same device while 13 bits for
>devices should still be reasonably unique. oh yeah, i'll use lstat as
>well so that symbolic links have their own numbers as well.
>
>there. is everybody happy now? i'll release something right after i
>finish up some codepage work.
>
>-a
>
I am having problems with the same "16 bit" inode numbers
in the SAME directory.
I am using Red Hat 6.0 i386 with netatalk-1.4b2+asun2.1.4-37b.
I have four share volumes (each on its own ext2 file system).
The largest of these 4 volumes is 4 GB.
When I did the mkfs, I did not specify the number of inodes,
and it created on the 4 GB drive 1048576 inodes
which means it is a 20 bit inode number.
Therefore, I believe I created the code to do what Adrian wanted,
but with the following changes:
1 bit: directory/file identifier (set == it's a file)
11 bits: device
20 bits: inode
Here is my diff, I have compiled it, but not tested it.
I have not setup a test bed yet.
I only have my production system with 14 people using it
via netatalk at the moment.
So I was wondering,
is this the right patch to do what Adrian was planning to do?
diff -rc netatalk-1.4b2+asun2.1.4/etc/afpd/file.c
netatalk-1.4b2+asun2.1.4.new/etc/afpd/file.c
*** netatalk-1.4b2+asun2.1.4/etc/afpd/file.c Sun Jan 2 22:45:09 2000
--- netatalk-1.4b2+asun2.1.4.new/etc/afpd/file.c Tue Feb 1 11:43:12 2000
***************
*** 199,205 ****
#ifdef AFS
aint = htonl(st->st_ino);
#else AFS
! aint = htonl(( st->st_dev << 16 ) | (st->st_ino & 0x0000ffff));
#endif AFS
#if AD_VERSION > AD_VERSION1
}
--- 199,207 ----
#ifdef AFS
aint = htonl(st->st_ino);
#else AFS
! aint = htonl(( S_ISREG( st->st_mode ) ? 0x10000000 : 0 )
! | (( st->st_dev << 20 ) & 0x7ff00000 )
! | (st->st_ino & 0x000fffff));
#endif AFS
#if AD_VERSION > AD_VERSION1
}
diff -rc netatalk-1.4b2+asun2.1.4/etc/afpd/fork.c
netatalk-1.4b2+asun2.1.4.new/etc/afpd/fork.c
*** netatalk-1.4b2+asun2.1.4/etc/afpd/fork.c Mon Dec 13 22:29:26 1999
--- netatalk-1.4b2+asun2.1.4.new/etc/afpd/fork.c Tue Feb 1 11:43:54 2000
***************
*** 180,186 ****
#ifdef AFS
aint = st.st_ino;
#else AFS
! aint = ( st.st_dev << 16 ) | ( st.st_ino & 0x0000ffff );
#endif AFS
#if AD_VERSION > AD_VERSION1
}
--- 180,188 ----
#ifdef AFS
aint = st.st_ino;
#else AFS
! aint = ( S_ISREG( st.st_mode ) ? 0x10000000 : 0 )
! | (( st.st_dev << 20 ) & 0x7ff00000 )
! | (st.st_ino & 0x000fffff);
#endif AFS
#if AD_VERSION > AD_VERSION1
}
Thank you,
Robert Bell.
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:29:57 EST