[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: This week's NEWS
Fwd: This week's NEWS
Sun, 3 Jun 2007 09:25:58 +0100
---------- Forwarded message ----------
From: James Youngman <address@hidden>
Date: Jun 3, 2007 9:24 AM
Subject: Re: This week's NEWS
On 6/2/07, address@hidden <address@hidden> wrote:
I just committed this week's changes.
Thanks. I am copying the list on the email, hope you don't mind.
[edit: this time, actually sending it to the list]
ext2 attribute support is working fine, now (relying on the library, as
I noticed two things:
1. in the few places where base_name() is used, the memory is not
freed. Is this intentional? If not, I can fix it.
It's a hangover from the days when we used to use basename(). The
basename() function does not allocate memory. The fact that the
buffer returned by base_name() is not freed is not intentional. I'm
sure the same problem affects both 4.3.x and 4.2.x. If you fix it,
could you mail it to me as a separate patch?
2. I didn't know that find changes the cwd before calling predicate
functions. This behaviour, or rather my ignorance concerning it,
led to pred_ext2attr() giving apparently mysterious "file not
found" errors. This was the more irritating as pred_xattr() did
not show this behaviour
Do they need to be two separate predicates?
-- because you seem to have added a clause
to ignore ENOENTs . Why did you do that? Can I remove it?
It doesn't seem to make sense to me.
Most predicates which access files need to cope with the possibility
that their target is deleted in between the time that the directory
entry data was read (e.g. by fts()) and the file is processed. This
time window can be reasonably large, certainly large enough for some
other pcess to delete the file.
As regards handling the current directory, this has latterly become
rather complex. You need to use this kind of approach these days:
const char *filename;
struct access_check_args *args = context;
if ((rv = access(args->filename, args->access_type)) < 0)
args->cb_errno = errno;
struct access_check_args args;
args.filename = state.rel_pathname;
args.access_type = access_type;
args.cb_errno = 0;
return 0 == run_in_dir(state.cwd_dir_fd, access_callback, &args);
pred_writable (const char *pathname, struct stat *stat_buf, struct
The reason for this is that find may or may not change CWD as it goes,
depending on which binary you are running and how it is configured
(e.g. the value of ftsoptions in ftsfind.c, the availability of
/proc/N/fd, and whether you are running the "find" or "oldfind"
The hacking with run_in_dir() is not always necessary if the OS or
gnulib provides a *at() function, like fstatat(). But the pathname
you pass to such functions in any case needs to be state.rel_pathname.
There are other reasons also for this difference between
state.relpathname and the pathname argument given to predicate
functions. In the arbitrary case, it will be impossible to stat the
pathname passed to the predicate function, even if the CWD is the same
as find's starting point, because that pathname will likely be too
long (sometimes) for the kernel's PATH_MAX limit.
Anyway, I hope you're content with my work. If you aren't at any time,
please say so.
All the best and a nice weekend to you,
Personal homepage: https://viridian.dnsalias.net/~sky/homepage/
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83
- Fwd: This week's NEWS,
James Youngman <=