Re: [Libguestfs] [PATCH 5/5 v3] fuse: Add tests for guestmount.

On Wed, Nov 18, 2009 at 09:44:10AM +0000, Matthew Booth wrote: >> +stage Checking file modes of initial content >> +[ "$(stat -c %a empty)" = "644" ] >> +[ "$(stat -c %a hello.txt)" = "644" ] >> +[ "$(stat -c %a world.txt)" = "644" ] > > You need to explicitly set the umask to 022 at the beginning of the > script for this to be reliable. libguestfs guarantees the initial umask already: http://libguestfs.org/guestfs.3.html#guestfs_umask http://git.annexia.org/?p=libguestfs.git;a=blob;f=daemon/guestfsd.c;h=db0...

>> +stage Checking sizes of initial content >> +[ "$(stat -c %s empty)" -eq 0 ] >> +[ "$(stat -c %s hello.txt)" -eq 5 ] >> +[ "$(stat -c %s world.txt)" -eq 11 ] > > While you're at it, you could add tests for every other stat field. Yup, I've checked most of them, but more would be better. >> +# This fails because of caching. The problem is that the linked file >> +# ("hello.txt") is cached with a link count of 2. unlink("link") >> +# invalidates the cache for "link", but_not_ for "hello.txt" which >> +# still has the now-incorrect cached value. However there's not much >> +# we can do about this since searching for all linked inodes of a file >> +# is an O(n) operation. >> +#[ "$(stat -c %h hello.txt)" -eq 1 ] > > Eurgh. What's the impact of not caching? It's really really slow. Note that the problem here is fairly minor. You'll see a link count of 2 instead of 1 for just a few seconds. > Alternatively, inotify can spot an updated link count. What's the > potential for adding asynchronous cache invalidation from the daemon? I don't think inotify helps here ... The linked file could be anywhere in the whole filesystem, so you'd have to have inotify watches in every single directory in the filesystem.