Re: [AVFS] Inode problem and own release

> I thought about the inode problem I mentioned previously but I didn't
> came up with a solution. The calculation in src/state.c:297
> 
>       buf->ino = (int) stf + st_paramhash(sf->stent->param);
> 
> results in 0 but because stf is NULL and sf->stent->param is the empty
> string (for /#avfsstat/cache) I think changing the hash function
> wouldn't help much. I currently prefer to take additional information
> into account. For example sf->stent->ent->name is a good candidate which
> is the last path component. More expensive is of course to use the whole
> path for the hash by accessing sf->stent->ent->parent...
> In any case access to struct entry is necessary which is a private
> struct in namespace.c. I can think of two solutions: move the struct
> definition to namespace.h or add a wrapper function to return the name
> (or full path name).
> A new inode calculation could be:
> 
> buf->ino = (int) stf + st_paramhash(sf->stent->param) + st_paramhash(
> sf->stent->ent->name);
> 
> and wrapping the whole expression in a new function to avoid inode
> number 0 and 1.
> What do you think about this?

Sounds fine.

> I'm planning the next release of my file manager and want to provide a
> patched avfs version. I attached the patch I want to use which differs
> from the previous version only by setting the version to 0.9.4 so I can
> require this version in my configure script. Is this okay with you?

Yes.  If I release 0.9.4 your changes will be in it :)

Thanks,
Miklos


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30