netatalk 4.5.0
Free and Open Source Apple Filing Protocol (AFP) Server
Loading...
Searching...
No Matches
dbd_lookup.c File Reference

CNID salvation spec. More...

`#include <arpa/inet.h>`
`#include <errno.h>`
`#include <stdio.h>`
`#include <string.h>`
`#include <sys/param.h>`
`#include <atalk/cnid_bdb_private.h>`
`#include <atalk/cnid.h>`
`#include <atalk/logger.h>`
`#include "dbd.h"`
`#include "dbif.h"`
`#include "pack.h"`

## Functions
int | dbd_lookup (DBD *dbd, struct cnid_dbd_rqst *rqst, struct cnid_dbd_rply *rply)
| This returns the CNID corresponding to a particular file.

## Detailed Description

CNID salvation spec.

general rule: better safe then sorry, so we always delete CNIDs and assign new ones in case of a lookup mismatch. afpd also sends us the CNID found in the adouble file. In certain cases we can use this hint to determince the right CNID.

The lines...

Id Did T Dev Inode Name
============================
a b c d e name1
-->
f g h i h name2
c
size_t c
Definition dircache.c:257
g
static gcry_mpi_t g
Definition uams_dhx2_pam.c:41

...are the expected results of certain operations. (f) is the speced CNID, in some cases it's only intermediate as described in the text and is overridden by another spec.

## 1) UNIX rename (via mv) or inode reusage(!)

Name is possibly changed (rename case) but inode is the same. We should try to keep the CNID, but we can't, because inode reusage is probably much to frequent.

rename:

15 2 f 1 1 file
-->
15 x f 1 1 renamedfile

inode reusage:

15 2 f 1 1 file
-->
16 y f 1 1 inodereusagefile
Result in dbd_lookup (-: not found, +: found):
+ devino
- didname
dbd_lookup
int dbd_lookup(DBD *dbd, struct cnid_dbd_rqst *, struct cnid_dbd_rply *)
This returns the CNID corresponding to a particular file.
Definition dbd_lookup.c:141
devino
int devino(DB *dbp, const DBT *pkey, const DBT *pdata, DBT *skey)
Definition pack.c:81
didname
int didname(DB *dbp, const DBT *pkey, const DBT *pdata, DBT *skey)
Definition pack.c:67

Possible solution:

None. Delete old data, file gets new CNID in both cases (rename and inode). If we got a hint and hint matches the CNID from devino we keep it and update the record.

## 2) UNIX mv from one folder to another

Name is unchanged and inode stays the same, but DID is different. We should try to keep the CNID.

15 2 f 1 1 file
-->
15 x f 1 1 file
Result in dbd_lookup:
+ devino
- didname
dbd_lookup
int dbd_lookup(DBD *dbd, struct cnid_dbd_rqst *rqst, struct cnid_dbd_rply *rply)
This returns the CNID corresponding to a particular file.
Definition dbd_lookup.c:141

Possible solution:

strcmp names, if they match keep CNID. Unfortunately this also can't be distinguished from a new file with a reused inode. So me must assign a new CNID. If we got a hint and hint matches the CNID from devino we keep it and update the record.

## 3) Restore from backup i.e. change of inode number – or emacs

15 2 f 1 1 file
-->
15 2 f 1 2 file
Result in dbd_lookup:
- devino
+ didname

Possible fixup solution: test-suite test235 tests and ensures that the CNID is changed. The reason for this is somewhat lost in time, but nevertheless we believe our test suite.

Similar things happen with emas: emacs uses a backup file (file~). When saving because of inode reusage of the fs, both files most likely exchange inodes.

15 2 f 1 1 file
16 2 f 1 2 file~
--> this would be nice:
15 2 f 1 2 file
16 2 f 1 1 file~
--> but for the reasons described above we must implement
17 2 f 1 2 file
18 2 f 1 1 file~
Result in dbd_lookup for the emacs case:
+ devino --> CNID: 16
+ didname -> CNID: 15
CNID
#define CNID(a, b)
Definition etc/afpd/directory.h:96

devino search and didname search result in different CNIDs !!

Possible fixup solution: to be safe we must assign new CNIDs to both files.

## Function Documentation

## ◆ dbd_lookup()

int dbd_lookup | ( | DBD * | dbd,
|  | struct cnid_dbd_rqst * | rqst,
|  | struct cnid_dbd_rply * | rply )

This returns the CNID corresponding to a particular file.

Note
  It will also fix up the database if there's a problem.