On Mon, Jul 31, 2006, EV wrote: > > 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...
Yes. Everything works fine if you use a file which is already in the filetable. I tried adding calls to kfs_flush() and they work fine for files which already exist. Just not for the one currently being created. The main problem with the method described above is that you cannot guarantee that any lkarmafs calls will be made again after the file has been written. Even destroy() won't be called if the filesystem is shut down uncleanly. The other problem is that you have two unsatisfactory choices for making the file appear on the karma. Either you don't add properties (so it isn't seen by the karma) until the next call, which is pretty unintuitive for the end user, or you add incorrect properties and then hope to update them later. In the meantime, the file is accessible from the karma but with incorrect properties. > > 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...] Because you need the whole file in order to generate a correct rid. > > 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). Fair enough. I suggested the former because I think that applications should not need to know how the device is connected. But since that is effectively what is required in this situation, maybe your suggestion is better. > > 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? The properties file. The call would update the properties for the fid and write the **1 file by calling lk_karma_update_file_details(), I'm not all that fussed what the function is called. As mentioned in another email, in the long term I would like to remove the properties structure from the libkarma interface altogether. > > 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). I guess that one would do. > 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. Me too. Keith. ------------------------------------------------------------------------- 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
