On Thu, 17 Oct 2019 23:58:04 +0900 "J. R. Okajima" <hooanon...@gmail.com> wrote:
> James B: > > No worries, it's nothing urgent. For now I just use aufs without the patch. > > Thank you for looking into this. > > Now I am fixing the bug. Almost done. Dear Junjiro-san, Thank you. > One thing left is to support > lseek fully. I mean, if your /proc/mounts has 1000 bytes and lseek(2) > to 1, then you may expect read(2) will return 999. It seems hard for > seq_file (linux kenel) to support lseek(2). Yes, noted. I think it is unlikely that anyone wants to do a random lseek on /proc/mounts. So a complete solution like that is probably not necessary. > My current fix retuns 0 for > this case. But if your read(2) 1000 bytes and lseek(2) to 0 (full > rewind), and read(2) will return 1000 again. > > Is it acceptable for you? Yes, this would work. The use case that I'm looking for this is this: a) open /proc/mounts b) read it fully c) poll the file handle d) if /proc/mount changes, I will get notified via the poll (this changes happens because of mount/unmount) e) I will lseek to 0 and read it fully again f) repeat to step (c) And in this case, your solution to lseek (0) works beautifully. Thank you again. cheers! -- James B
