Hi all, I've been trying to use obexfs for synchronizing some files with my bluetooth-enabled Nokia phone. So far, it has been working pretty ok and fast. However, it is very inconvenient that obexfs does not support renaming of files on non-Siemens phones.
I understand that this is a limitation of the OBEX protocol, and thus cannot easily (or efficiently) be overcome. However, the current behaviour is pretty unexpected: renames silently fail. I've started on a implementation of a proper rename function, using the totally inefficient method of getting a file, putting it under the new name and removing the old file. This is a braindead way of doing this, but it seems to be the only way we can manage it. I've implemented this in the obexfs fuser handler for renaming files already. I'm currently working on doing the same (recursively) for directories as well, but I'm running into a small problem. To rename a directory, I create the new directory, loop all entries in the original directory and rename each of them recursively. This works in theory, but not in practice. When one of the entries in the directory renamed is again a directory, this process is repeated recursively. When the new (sub)directory is created, the obexftp library completely empties its cache (since directory creation always creates parent directories as needed, there is no way for obexftp to know up to where the caches need to be invalidated, so it invalidates all of them). As soon as the cache is invalidated, the directory pointer (as returned by obexftp_readdir, which is just a pointer into the cache) is invalidated as well, meaning the next call to obexftp_readdir will just return NULL and all remaining entries will not be renamed. On closer inspection, this invalidation also happens when deleting the original (sub)directory, which would also invalidates the dirlisting we're traversing. On even closer inspection, I found that all cache invalidation calls in obexftp invalidate the entire cache, not of the calls there use the second argument to cache_purge. To fix this problem, I see a few options: * Make cache invalidation (a lot) smarter. This means that just invalidating the entire cache should never happen. When doing a mkdir, only the directories involved in the created path should be invalidated (non-recursively), which is sufficient for this problem (the new directory will never be inside the old directory when renaming). This also means that the cache must be updated instead of just invalidated when removing a file. * Use some kind of locking or reference counting mechanism to prevent the directory entries from being free'd until after we've finished iterating them. This is probably not so elegant and error-prone. * Make the rename function in obexfs keep a local copy of the directory listing. So, iterate the entire directory, saving all the names, and only then start renaming them recursively. This is not very elegant, but would probably work. * Don't iterate the directory listing, but call obexftp_opendir every time again to process the first entry in the directory. Since the recursive call to rename will always remove the entry when it is done renaming, the next call will always return the next (i.e., then first) entry, until all entries have been renamed (i.e., removed) and the directory is empty. This does require obexftp to retrieve a new directory listing from the device for each entry in the directory being renamed, so this will will make the approach even less efficient than it is now. Overall, I think fixing the cache code in obexftp is the cleanest and most efficient approach (also having a positive effect on general performance). However, I'm trying to limit my changes to just obexfs for now, so I'll probably try to make obexfs cache directory listings first. Not very pretty, but it should work. If there is interest, I might have a go at improving the caching structure of obexftp later on. Progress so far (and a few somewhat finished patches) on http://git.stderr.nl/gitweb?p=matthijs/upstream/obexfs.git in the rename-fixes branch. Comments are welcome! Gr. Matthijs
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
_______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
