2006-07-31: Keith Bennett dixit: > On Sun, Jul 30, 2006, Keith Bennett wrote: > > Oh right, now I get it. Our problem is that things like > > taglib and the rid generation code need to be passed a > > filename, which we don't have since we are only given raw > > data. However, lkarmafs itself provides a virtual filename > > which could be passed to these function calls instead. Very > > cunning. > > > > Well, we have most of the pathname because it is passed to us > > by FUSE. The only thing that is missing is the mountpoint. I > > couldnt find any sensible way of getting that via fuse > > either. But we can cheat. The mountpoint is passed in as one > > of the initial arguments. We just need to determine which one > > it is and then store it somewhere for later use. Bingo. > > Problem solved. No messy temporary files. No distinction > > between USB and ethernet. > > Nope. That doesn't work either. FUSE doesn't add the entry to > the filetable until after the release() call has completed.
Too bad :( > One possible workaround is to add the file to a "properties > need updating" list and do the work next time a call is made > and/or when destroy() is called. I think that this is even more > of a hack than the temporary file method, though. I'd like to think a little bit more about this solution. Did you manage to access lkarmafs (virtually-)created files (of course after having been released) from within the lkarmafs process? I'm asking before I seem to remember I tried it some time ago with no success... > I propose that we just bite the bullet and write the whole file > to /dev/shm (with /tmp as fallback) when the ethernet device is > in use. In case we have to arrive to this point, why the whole file? [you know, I regularly handle radio broadcast recordings which make several handred MB each...] > To this end, I think that three calls to libkarma need to be > added. The first call is lk_rio_can_write_props(karma) which > will return zero if the ethernet device is in use and non-zero > for USB. If zero is returned then we know that a temporary file > is required. I'd name this first call lk_karma_usbOrLan(karma) or just lk_karma_usb(karma). However I think it might be superfluous (see below). > The second call is lk_rio_write_props(karma, fid). Internally, > this will generate the properties based on the fids0/_00???/??0 > file, but lkarmafs need not be aware of this. It will return > zero on a successful USB write Successful USB write? write what? > and a non-zero value if the ethernet device is in use or the > USB write failed. > > Finally, a lk_rio_write_props_file(karma, fid, filename) call > which will generate the properties based on the given filename > (ie. /dev/shm/whatever). Why do we need two calls? I think we need just one such as lk_rio_import_props_from_tags(karma, fid). Moreover, by choosing an appropriate naming scheme based on the fid for the temporary files, lk_rio_import_props_from_tags() can be used uniformly both for the USB and Ethernet interfaces. In rio_rw.c we can know which interface is being used by internally calling lk_karma_usbOrLan() and, depending of the interface, try to open some fids0/_00???/??0 or something like /dev/shm/lk_00?????0. So, all in all, applications (lkarmafs) would need just the call lk_rio_import_props_from_tags(karma, fid). Alternatively, if we prefer to leave libkarma unaware of temporary file naming, etc., we can implement this call as: lk_rio_import_props_from_tags(karma, fid, filename). In this case, the application (lkarmafs) should determine which interface is being used, create the temp file if necessary, and call lk_rio_import_props_from_tags() to import the properties. I think I'm more in favour of this last alternative. > As you mentioned before, the temporary file will need to be > passed around with the fuse_file_info structure. O.K. More comments? EV. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-karma-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
