On Thu, Oct 21, 2010 at 1:02 PM, Cedric BAIL <[email protected]> wrote: > On Thu, Oct 21, 2010 at 4:45 PM, Gustavo Sverzut Barbieri > <[email protected]> wrote: >> On Thu, Oct 21, 2010 at 11:44 AM, Cedric BAIL <[email protected]> wrote: >>> On Thu, Oct 21, 2010 at 1:03 PM, Gustavo Sverzut Barbieri >>> <[email protected]> wrote: >>>> On Thu, Oct 21, 2010 at 4:10 AM, Cedric BAIL <[email protected]> wrote: >>>>> On Wed, Oct 20, 2010 at 7:20 PM, Gustavo Sverzut Barbieri >>>>> <[email protected]> wrote: >>>>>> On Wed, Oct 20, 2010 at 2:42 PM, Enlightenment SVN >>>>>> <[email protected]> wrote: >>>>>>> Log: >>>>>>> * eio: add eio_file_chmod and eio_file_chown. >>>>>> >>>>>> Okay, we're in a thread, but recursive operations should use the "at" >>>>>> variants to speed them up. Would you mind implementing them as well >>>>>> (using your code as fallback when they are not available)? It's >>>>>> basically dirfd(DIR *d) then use this as parameter for openat(), >>>>>> unlinkat(), ... I'm also following systemd and see they're >>>>>> effectively using it for good! (may also be used as a good source of >>>>>> examples git://anongit.freedesktop.org/systemd) >>>>> >>>>> I am not really sure how much it could help. As we need to separate >>>>> the listing stage from the action, so that we can send progress >>>>> information. I will look how we can use that, but I don't expect >>>>> something really useful here. >>>> >>>> still the actual operation is on the thread and recursively walking >>>> directories is faster as a good amount of the path is already >>>> resolved, you just incrementally use another point. If you have >>>> /a/b/c/d/e/f, to walk to /a/b/c/d/e/f/g the kernel needs to resolve >>>> the other paths AGAIN. With *at variants it does not. >>> >>> Yes, of course, that's not my point. The problem is that I do close >>> all ressource before listing another one, because I fear ressource >>> consuption a lot. But maybe I am wrong and it would not be a problem. >>> Right now the bug I would like to fix, is infinite recursion. I don't >>> know yet how to cleanly solve that, maybe you have an idea. >> >> is it a code bug or due symlink loops? > > symlink loops of course :)
then it's the good old way to avoid loops in a linked list. Keep a reference and if you reach it again, you stop. You can do this in filesystems by resolving the realpath (if symlinks) and if the symlink is parent of the folder you're walking, you stop. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
