st_nlink should be set to the number of sub directories + 2 (. & ..)
Like this directory structure:
/dir/. st_nlink = 5 (.+..+/dir/dir1/+/dir/dir2/+/dir/dir3/)
/dir/.. st_nlink = 23 (number of dirs in root dir)
/dir/dir1/. st_nlink = 3 (.+..+/dir/dir1/dir1b)
/dir/dir1/.. st_nlink = 5
/dir/dir1/dir1b/. st_nlink = 2 (no subdirs except .+..)
/dir/dir1/dir1b/.. st_nlink = 3
/dir/dir1/file1 st_nlink = 1
/dir/dir2/. st_nlink = 2 (no subdirs except .+..)
/dir/dir2/.. st_nlink = 5
/dir/dir3/. st_nlink = 2 (no subdirs except .+..)
/dir/dir3/.. st_nlink = 5
/dir/file1 st_nlink = 1
/dir/file2 st_nlink = 1
I don't think we can use any cache to determine the number of
directories very easy in an accurate way.
Let's say a user trig a call to FS_dir(dirfunc) which create the
directory listing.
Some milli-seconds (or longer) later the user will call
fstat("/dir/")
fstat("/dir/dir1")
fstat("/dir/dir2")
fstat("/dir/dir3")
fstat("/dir/file1")
fstat("/dir/file2")
to get extended information about the dir-entry.
Some other process might have made a new FS_realdir and found more
1-wire devices on the network after the first FS_dir() and before
fstat("/"). This will result into a wrong result from fstat("/").
Even if we save a new cache entry to hold the data (st_nlink) for
each directory, it won't be accurate since it could have changed
by another thread.
Perhaps it's possible to save the st_nlink + threadid in a separate
cache to hold the correct value for x seconds. (don't know if it's
possible yet... just an idea)
If a new thread from fuse calls fstat("/dir1/") WITHOUT doing a
FS_dir("/dir/") first, then we don't have a valid cache entry
for st_nlink, and fstat("/dir1/.") will force us to do a complete search
of all devices in that directory first before returning st_nlink.
Am I totally wrong here, it does it make any sense for you...?
/Christian
On Fri, 2005-04-15 at 19:05, Alfille, Paul H.,M.D. wrote:
> What do you mean by subdir? Does it require a full directory listing? At least
> it would "prime the pump" for the subsequent directory traversal by filling
> the
> cache.
>
> The current directory cache scheme has us add each entry, and then a null
> entry
> to flag the end of the directory. If we need to keep more aggregate data
> (number
> of entries, existence of simultaneous or alarm-capable devices,...) we could
> just make a new cache entry to hold all the "aggregate" data. This would also
> help eliminate a subtle potential race condition when the directory times out
> while being listed.
>
> Paul
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Christian Magnusson
> Sent: Friday, April 15, 2005 11:21 AM
> To: owfs-developers
> Subject: RE: [Owfs-developers] OWFS and FUSE Debugging with UML
> (UserMode Linux)
>
>
>
> I was trying to fix it this afternoon...
>
> in FS_fstat.c:
> stbuf->st_nlink = 2 ; // plus number of sub-directories
> stbuf->st_nlink += FS_nr_subdirs(&pn) ;
>
> Tried to read from cache how many subdirs was returned by FS_dir()
> but I stumbled into some other problem when I tried to do it.
> It seems like I forgot to cache devices returned from ServerDir().
>
> Is it worth the effort of setting st_nlink to the correct value
> or should we keep it the way it is?
>
> /Christian
>
>
>
> On Fri, 2005-04-15 at 09:49 -0400, Alfille, Paul H.,M.D. wrote:
> > I've asked this question of fuse. This is the response I got:
> >
> > From: <[EMAIL PROTECTED]>
> > Re: "find" command
> > 2004-05-11 12:14
> > use the -noleaf option to find
> > (find uses the following parameters to determine whether it should recurse
> > into a subdirectory)
> >
> > nr_links must be >= 3
> > size must be > 0
> > and must be a driectory
> >
> > so just return those in the getattr for your directories and you wont have
> > to use -noleaf.
> >
> > ---
> > Cody Pisto <[EMAIL PROTECTED]>
> >
> > > I"m having trouble getting the find command to search through fuse
> > > directories. What settings do I need in "getattr"?
> > >
> > > Paul Alfille
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_ide95&alloc_id396&opĚk
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
