> > Look at this strace snipplet from 'find /mnt/fuse/tmp/test':
> >
> > lstat64("/mnt/fuse/tmp/test", {st_dev=makedev(0, 14), st_ino=3}...) = 0
> ...
> > open ("/mnt/fuse/tmp/test", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
> > = 5
> > fstat64(5, {st_dev=makedev(0, 14), st_ino=5}) = 0
>
> >
I'm trying to convert CVS M4 to use clean-tmp instead of tmpfile-safer, in part
so I can use the closeout module while minimally impacting the current code
base usage of temporary FILE* for storage of large diversions. But in the
process, I have several questions. It looks like using mkstemp
(
Hi,
The ordered set datatype is missing an operation: search of the least
element >= a given threshold. I'm adding it, since the 'list' modules will
need it.
2006-10-03 Bruno Haible <[EMAIL PROTECTED]>
* gl_oset.h (gl_setelement_threshold_fn): New type.
(gl_oset_search_atleast)
A weird copy&paste bug.
2006-10-03 Bruno Haible <[EMAIL PROTECTED]>
* gl_rbtreehash_list.c (gl_rbtreehash_list_implementation): Renamed
from gl_avltreehash_list_implementation.
*** gnulib-20060928/lib/gl_rbtreehash_list.c2006-10-03 22:46:43.0
+0200
--- gnulib-20060
Hi,
I'm applying this. That this bug stayed so long is an indication that most
compilers nowadays support 'inline'.
2006-10-03 Bruno Haible <[EMAIL PROTECTED]>
* gl_oset.c (gl_oset_add): Fix return type.
*** gnulib-20060928/lib/gl_oset.c 2006-09-19 00:51:16.0 +0200
---
Hi,
In lock.m4 the separation into an "early" part and a normal part was not
done right: It was still not possible to invoke AC_GNU_SOURCE after
gl_LOCK_EARLY.
I fixed it now.
2006-10-01 Bruno Haible <[EMAIL PROTECTED]>
Make it possible to invoke AC_GNU_SOURCE after gl_LOCK_EARLY.
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> Thanks for forwarding that.
>> I confess I hadn't looked at the original bug report.
>> Just did, and see that it's a different problem than I first thought.
>> I now see that this is about the dev/ino check when traversing "up"
>> to return to a previou
> Thanks for forwarding that.
> I confess I hadn't looked at the original bug report.
> Just did, and see that it's a different problem than I first thought.
> I now see that this is about the dev/ino check when traversing "up"
> to return to a previously visited directory.
>
> I find it hard to b
"James Youngman" <[EMAIL PROTECTED]> wrote:
> On 10/4/06, Jim Meyering <[EMAIL PROTECTED]> wrote:
>
>> The resulting down side is that the old version of find is
>> susceptible to a nasty type of attack when traversing a directory
>> that is writable by another user.
>
> I think even oldfind (i.e.
On 10/4/06, Jim Meyering <[EMAIL PROTECTED]> wrote:
The resulting down side is that the old version of find is
susceptible to a nasty type of attack when traversing a directory
that is writable by another user.
I think even oldfind (i.e. version 4.2.x and the alternate binary in
4.3.x) has suf
[I'm moving the discussion to the bug-gnulib mailing list,
since this concerns the gnulib fts module. ]
"James Youngman" <[EMAIL PROTECTED]> wrote:
> For your info.
Hi James,
Thanks for forwarding that.
I confess I hadn't looked at the original bug report.
Just did, and see that it's a differe
"Dmitry V. Levin" <[EMAIL PROTECTED]> wrote:
> 2006-10-02 Dmitry V. Levin <[EMAIL PROTECTED]>
>
> * io/fts.c (fts_close, fts_build, fts_palloc): Remove redundant
> checks.
Thank you.
I've applied those changes to the version of fts.c in gnulib, too.
If you have applications that use
12 matches
Mail list logo
