I don't think it is so unusual to have a directory listing become out of
date.

This must happen frequently while one process is navigating the directory,
another can change entries in it.

The first process won't know anything about changes to the structure once
it has traversed that particular node.  Why would this example be any
different ?




|---------+------------------------------------------->
|         |           Christian Magnusson             |
|         |           <[EMAIL PROTECTED]|
|         |           m>                              |
|         |           Sent by:                        |
|         |           [EMAIL PROTECTED]|
|         |           ceforge.net                     |
|         |                                           |
|         |                                           |
|         |           19/04/2005 12:50                |
|         |           Please respond to               |
|         |           owfs-developers                 |
|         |                                           |
|---------+------------------------------------------->
  
>-------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                |
  |       To:       owfs-developers <owfs-developers@lists.sourceforge.net>     
                                |
  |       cc:                                                                   
                                |
  |       Subject:  RE: [Owfs-developers] OWFS and FUSE Debugging with    UML   
(UserMode   Linux)              |
  
>-------------------------------------------------------------------------------------------------------------|




On Tue, 2005-04-19 at 09:31 +0100, [EMAIL PROTECTED] wrote:
> What is the expected value of st_nlink - should it include the number of
> dirs in sub-dirs as well.
> That doesn't sound right to me.
>

yes... It should be like that. Temp-sensor 10.xxxxxxxxxx/. should have
st_nlink=2 since there are no directories in that sensor.
DS1991 02.xxxxxxxxxxx/. should have st_nlink=4 since there are two
directories. (/settings and /pages)


> Once a directory is enumerated, the number of sub-dirs is known and
> contained in a linked list.
> Iterating that list to count the sub-dirs should be trivial.
>

The problem is the root directories on each server like /bus.0/bus.0/.

It could contain:
/bus.0/bus.0/.                       st_nlink = 7 + xxxx
/bus.0/bus.0/..
/bus.0/bus.0/settings/
/bus.0/bus.0/statistics/
/bus.0/bus.0/structure/
/bus.0/bus.0/system/
/bus.0/bus.0/uncached/

+ some devices
/bus.0/bus.0/10.0000000000/

+ eventually some more directories
/bus.0/bus.0/bus.0/
/bus.0/bus.0/bus.1/
/bus.0/bus.0/bus.2/
/bus.0/bus.0/alarm/
/bus.0/bus.0/simultaneous/

This means that fstat("/bus.0/bus.0/.") have to make a complete
list of the remote server before returning the correct st_nlink,
or perhaps return the number of directories saved in the cache.

If you run 'ls /bus.0/bus.0' it's usually implemented as

while ((entry = readdir(dir)) != NULL) {
   if(!(cur = my_fstat(fullname, strrchr(fullname, '/') + 1))) continue;
   add_file_to_list(cur);
}
closedir(dir);
print_all_files_in_list();

It makes a fstat() after each entry, and it's hard to know the result
of fstat('/bus.0/bus.0/.') before the whole directory is read once
at least.

I'm sure it will be fixed soon, but I haven't come up to a fool-proof
solution for it that works for many simultaneous readdir() calls. I
think fstat() might return wrong value if new devices (or alarm)
are detected on the second call to readdir().

/Christian





-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein 
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries 
and affiliates



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to