From: Paul A. <pal...@ea...> - 2004-03-24 01:49:12
|
The current changes in the CVS for FUSE seem to break OWFS. 'struct fuse_statfs' declared inside parameter list. Is this something permanent that I should work around? Paul Alfille |
From: Miklos S. <msz...@in...> - 2004-03-24 08:24:51
|
> The current changes in the CVS for FUSE seem to break OWFS. > > 'struct fuse_statfs' declared inside parameter list. > > Is this something permanent that I should work around? Yep. You can support both interfaces by doing a #if defined(FUSE_MAJOR_VERSION) && FUSE_MAJOR_VERSION > 1 [new statfs interface] #else [old statfs interface] #endif Miklos |
From: Paul A. <pal...@ea...> - 2004-03-25 00:31:24
|
Ok. To be complete: #if defined(FUSE_MAJOR_VERSION) && FUSE_MAJOR_VERSION > 1 int Your_statfs( const char * path, struct statfs st) ; #else int Your_statfs( struct fuse_statfs fst) ; #endif /* see man 2 statfs */ struct statfs { long f_type; /* type of filesystem (see below) */ long f_bsize; /* optimal transfer block size */ long f_blocks; /* total data blocks in file system */ long f_bfree; /* free blocks in fs */ long f_bavail; /* free blocks avail to non-superuser */ long f_files; /* total file nodes in file system */ long f_ffree; /* free file nodes in fs */ fsid_t f_fsid; /* file system id */ long f_namelen; /* maximum length of filenames */ } ; /* Whereas fuse_statfs */ struct fuse_statfs { long block_size; long blocks; long blocks_free; long files; long files_free; long namelen; } ; On Wed, 2004-03-24 at 03:24, Miklos Szeredi wrote: > > The current changes in the CVS for FUSE seem to break OWFS. > > > > 'struct fuse_statfs' declared inside parameter list. > > > > Is this something permanent that I should work around? > > Yep. You can support both interfaces by doing a > > #if defined(FUSE_MAJOR_VERSION) && FUSE_MAJOR_VERSION > 1 > [new statfs interface] > #else > [old statfs interface] > #endif > > Miklos |
From: Paul A. <pal...@ea...> - 2004-03-25 01:12:05
|
By the way, is statfs actually useful for anything? Should I bother supporting it or just let the FUSE defaults do their work. Paul |
From: Miklos S. <msz...@in...> - 2004-03-25 08:35:55
|
> By the way, is statfs actually useful for anything? Should I bother > supporting it or just let the FUSE defaults do their work. Current default isn't so nice because it returns ENOSYS, which means that an error is printed in 'df' for the filesystem. But you can safely set all members to zero, if there is nothing useful to show. In the new statfs interface the f_type and f_fsid fields of struct statfs are ignored. Miklos |
From: Paul A. <pal...@ea...> - 2004-03-25 10:53:15
|
Does "current" mean both versions? Will we be getting a f_type for FUSE? Paul On Thu, 2004-03-25 at 03:35, Miklos Szeredi wrote: > > By the way, is statfs actually useful for anything? Should I bother > > supporting it or just let the FUSE defaults do their work. > > Current default isn't so nice because it returns ENOSYS, which means > that an error is printed in 'df' for the filesystem. But you can > safely set all members to zero, if there is nothing useful to show. > > In the new statfs interface the f_type and f_fsid fields of struct > statfs are ignored. > > Miklos |
From: Miklos S. <msz...@in...> - 2004-03-25 11:03:43
|
> Does "current" mean both versions? Yes. But in fact it would probably be better to provide a default "zero" fsstat, since many filesystems don't care but df output does look ugly if ENOSYS is returned. So I'll fix that in CVS so you won't have to implement the new interface. > Will we be getting a f_type for FUSE? f_type is filled in by the kernel (to FUSE_SUPER_MAGIC), but I haven't seen any uses of this field yet. If you think it could be useful, now is the time to extend the kernel interface. So anyone know of an application which uses f_type of struct statfs? Miklos |