On Sat, Apr 15, 2006 at 03:24:26PM +0200, Libor Vanek (libor.vanek@gmail.com) wrote:> > > However, with 256 I get "File name too long", as you did.> >> > Sure, as pointed in previous e-mail, several concatenated directories can exceed any resonable limit,> > even PATH_MAX (4k):> > $ pwd | wc> > 1 1 4113> >> > So it is wrong idea to transfer the whole name in one message, which> > will not only add huge overhead (for each subdir one must transfer the> > whole path for the parent dir), but can be impossible to allocate such a> > buffer in kernelspace to store the whole pathname.> > OK, so what would you suggest as the right "tool" to transfer these> (full path text) information?> > I see these options:> 1, Keep using procfs (I don't like it)> 2, Use connector and create such "communication protocol" that it'll> be able to transfer such long messages in more datagrams (even if> 99.99% of messages will fit 1 datagram)> 3, Some other API to transfer information to user-space and back?> > I'll probably go with 2, but I'd be more then happy to hear any> comments about this...

In general case using any tool you will be unable to transfer the wholepath in one shot, consider low memory condition and you try to allocatea page with high order.So it is required to split your path into multiple blocks, I wouldrecommend to use messages with names between slashes, i.e./home/test/aaa/bbb/ccc will be sent as 5 messages with /home, test, aaa,bbb and ccc data, this will also reduce overhead when there are severalfiles or directories in one parent dir. Each message should also includesome reference to which parent dir it belongs. This will also speedthings up noticebly, since you will not rescan the whole path when newfile is created, only parent dir.