File Owner and Group ID on Windows

File Owner and Group ID on Windows

[Eli Zaretskii]

I've just committed a series of changes, mainly to w32-specific files,
but also to dired.c, to query the w32 filesystems and report the owner
and group of every file.  (Up till now, Emacs on Windows would
attribute all the files to the user who was running the Emacs
session.)  This affects file-attributes,
directory-files-and-attributes, and Dired.

These changes required incompatible changes in `struct stat', so
please remove all *.o files (in src/oo-spd/i386/ and in
lib-src/oo-spd/i386/) before saying "make".

There could be some fallout, especially in code that was working until
now because all files appeared to be owned by the current user.  Now
this will change, which could cause Emacs think the user is trying to
change files she doesn't own.  VC is one place where such problems
could happen.  I'm asking Windows users to please be alert and report
any problems that could be related to this.

To temporarily work around any problems you bump into, you can set
w32-get-true-file-attributes to nil.

The new code needs some optimization, especially for networked drives;
I will add SID caching to do that.  Again, if you find Emacs too
sluggish, set w32-get-true-file-attributes to nil until performance
improves.

Note that lib-src programs now use our own version of `stat' as well
(this couldn't be avoided, due to incompatible layouts of `struct
stat'), so any problems with file accessibility from those programs
could also be due to some snafu I failed to resolve.  The version of
`stat' used by lib-src is much simpler and doesn't bother to look for
true file owner or even compute the inode, but any bugs I left there
could cause failures in previously working workflow.

Thanks.

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Fri, May 9, 2008 at 23:13, Eli Zaretskii <eliz@gnu.org> wrote:

> There could be some fallout, especially in code that was working until
> now because all files appeared to be owned by the current user.  Now
> this will change, which could cause Emacs think the user is trying to
> change files she doesn't own.  VC is one place where such problems
> could happen.  I'm asking Windows users to please be alert and report
> any problems that could be related to this.

emacs -Q
M-x server-start <RET>  =>  "The directory ~/.emacs.d/server is unsafe"

because

  (nth 2 (file-attributes "~/.emacs.d/server/")) == 1006
  (user-uid) == 123


  Juanma

Re: File Owner and Group ID on Windows

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Fri, May 9, 2008 at 23:13, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> There could be some fallout, especially in code that was working until
>> now because all files appeared to be owned by the current user.  Now
>> this will change, which could cause Emacs think the user is trying to
>> change files she doesn't own.  VC is one place where such problems
>> could happen.  I'm asking Windows users to please be alert and report
>> any problems that could be related to this.
> 
> emacs -Q
> M-x server-start <RET>  =>  "The directory ~/.emacs.d/server is unsafe"
> 
> because
> 
>   (nth 2 (file-attributes "~/.emacs.d/server/")) == 1006
>   (user-uid) == 123


Is this the maybe the same problem that I reported two days ago?

The message I sent had the title "Bug report about
server-ensure-safe-dir". I sent it to this list.

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Thu, Aug 21, 2008 at 03:35, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> Is this the maybe the same problem that I reported two days ago?

Possibly. I just got back from holidays and have quite a backlog of e-mail.

 Juanma

Re: File Owner and Group ID on Windows

[Eli Zaretskii]

> Date: Thu, 21 Aug 2008 03:27:20 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Fri, May 9, 2008 at 23:13, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > There could be some fallout, especially in code that was working until
> > now because all files appeared to be owned by the current user.  Now
> > this will change, which could cause Emacs think the user is trying to
> > change files she doesn't own.  VC is one place where such problems
> > could happen.  I'm asking Windows users to please be alert and report
> > any problems that could be related to this.
> 
> emacs -Q
> M-x server-start <RET>  =>  "The directory ~/.emacs.d/server is unsafe"
> 
> because
> 
>   (nth 2 (file-attributes "~/.emacs.d/server/")) == 1006
>   (user-uid) == 123

I cannot reproduce this with yesterday's CVS: user-uid returns 1004,
which is identical to what file-attributes returns for files owned by
me.  Are you using a recent CVS?  If so, could you please debug
through w32.c:init_user_info, where it sets the value of
dflt_passwd.pw_uid, and see what went wrong?  The value of 123
suggests that the syscalls to get the real owner and group of the
current Emacs process (starting at open_process_token) somehow failed.

Thanks.

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Thu, Aug 21, 2008 at 07:44, Eli Zaretskii <eliz@gnu.org> wrote:

> Are you using a recent CVS?

Yes.

> If so, could you please debug
> through w32.c:init_user_info, where it sets the value of
> dflt_passwd.pw_uid, and see what went wrong?

 get_token_information (...)  => 0
 GetLastError () => 998  (ERROR_NOACCESS)

though I see nothing obviously wrong with the args to get_token_information.

Hope this helps,

  Juanma

Re: File Owner and Group ID on Windows

[Eli Zaretskii]

> Date: Thu, 21 Aug 2008 16:14:51 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
>  get_token_information (...)  => 0
>  GetLastError () => 998  (ERROR_NOACCESS)

And what about the similar code in w32_system_process_attributes? does
it work for the Emacs process?  If it does, perhaps we need to open
the current process the same way we do there, and ask for
PROCESS_QUERY_INFORMATION and PROCESS_VM_READ types of access.  Can
you check that?

Also, do you know if this ever worked for you?  I don't think this
code was changed since May.

Finally, what kind of a machine is this failing on? is it a standalone
workstation or a machine behind a domain server?

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Thu, Aug 21, 2008 at 18:37, Eli Zaretskii <eliz@gnu.org> wrote:

> And what about the similar code in w32_system_process_attributes? does
> it work for the Emacs process?  If it does, perhaps we need to open
> the current process the same way we do there, and ask for
> PROCESS_QUERY_INFORMATION and PROCESS_VM_READ types of access.  Can
> you check that?

(assq 'euid (system-process-attributes) (emacs-pid)) => (euid . 1006)

> Also, do you know if this ever worked for you?  I don't think this
> code was changed since May.

I've checked out and tested at several points around your May changes,
and in all of them (user-uid) => 123, so I suppose it never worked.

> Finally, what kind of a machine is this failing on? is it a standalone
> workstation or a machine behind a domain server?

It's a standalone workstation (a laptop, not connected to anything
other than the cable modem). OS is Windows XP Home Edition, SP3.

   Juanma

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Fri, Aug 22, 2008 at 12:34, Juanma Barranquero <lekktu@gmail.com> wrote:

> (assq 'euid (system-process-attributes) (emacs-pid)) => (euid . 1006)

(assq 'euid (system-process-attributes (emacs-pid))) => (euid . 1006)

I mean.

   Juanma

segfault in system-process-attributes on GNU/Linux

[Bob Rogers]

   From: "Juanma Barranquero" <lekktu@gmail.com>
   Date: Fri, 22 Aug 2008 12:35:54 +0200

   (assq 'euid (system-process-attributes (emacs-pid))) => (euid . 1006)

   I mean.

      Juanma

Interesting.  When I evaluate:

	(system-process-attributes (emacs-pid))

on my GNU/Linux system (openSUSE 10.2, kernel 2.6.18.2) using emacs
updated from trunk a few minutes ago, I get the segfault shown below.

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

------------------------------------------------------------------------
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x810cf0b: file emacs.c, line 417.
Breakpoint 2 at 0x812573c: file sysdep.c, line 1133.
(gdb) r
Starting program: /usr/src/emacs/src/emacs 
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1221383984 (LWP 2242)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1221383984 (LWP 2242)]
0x081a2836 in Fsystem_process_attributes (pid=17936) at process.c:7417
(gdb) bt
#0  0x081a2836 in Fsystem_process_attributes (pid=17936) at process.c:7417
#1  0x0816f6d1 in Feval (form=139264877) at eval.c:2373
#2  0x0817013d in Ffuncall (nargs=2, args=0xbfd9d490) at eval.c:3042
#3  0x0819e9ab in Fbyte_code (bytestr=136537083, vector=136537100, maxdepth=40) at bytecode.c:678
#4  0x0816fdd2 in funcall_lambda (fun=136537028, nargs=2, arg_vector=0xbfd9d5c4) at eval.c:3229
#5  0x08170319 in Ffuncall (nargs=3, args=0xbfd9d5c0) at eval.c:3088
#6  0x08171866 in Fapply (nargs=2, args=0xbfd9d620) at eval.c:2530
#7  0x081718a7 in apply1 (fn=142976345, arg=139263053) at eval.c:2794
#8  0x0816c6e2 in Fcall_interactively (function=142976345, record_flag=137763017, keys=137801452) at callint.c:389
#9  0x08170171 in Ffuncall (nargs=4, args=0xbfd9d7a0) at eval.c:3048
#10 0x081703f5 in call3 (fn=137927273, arg1=142976345, arg2=137763017, arg3=137763017) at eval.c:2872
#11 0x08111ee3 in Fcommand_execute (cmd=142976345, record_flag=137763017, keys=137763017, special=137763017) at keyboard.c:10338
#12 0x0811dc0a in command_loop_1 () at keyboard.c:1879
#13 0x0816ed4c in internal_condition_case (bfun=0x811cd19 <command_loop_1>, handlers=137806257, hfun=0x81181d1 <cmd_error>) at eval.c:1511
#14 0x08117772 in command_loop_2 () at keyboard.c:1338
#15 0x0816ee02 in internal_catch (tag=137802233, func=0x811774f <command_loop_2>, arg=137763017) at eval.c:1247
#16 0x08118024 in command_loop () at keyboard.c:1317
#17 0x08118361 in recursive_edit_1 () at keyboard.c:942
#18 0x0811848a in Frecursive_edit () at keyboard.c:1004
#19 0x0810e762 in main (argc=1, argv=0xbfd9def4) at emacs.c:1689

Lisp Backtrace:
"system-process-attributes" (0xbfd9d3d0)
"eval" (0xbfd9d494)
"eval-expression" (0xbfd9d5c4)
"call-interactively" (0xbfd9d7a4)
(gdb) 

Re: segfault in system-process-attributes on GNU/Linux

[Eli Zaretskii]

> Date: Sat, 23 Aug 2008 12:10:11 -0400
> From: Bob Rogers <rogers-emacs@rgrjr.dyndns.org>
> Cc: 
> 
>    From: "Juanma Barranquero" <lekktu@gmail.com>
>    Date: Fri, 22 Aug 2008 12:35:54 +0200
> 
>    (assq 'euid (system-process-attributes (emacs-pid))) => (euid . 1006)
> 
>    I mean.
> 
>       Juanma
> 
> Interesting.  When I evaluate:
> 
> 	(system-process-attributes (emacs-pid))
> 
> on my GNU/Linux system (openSUSE 10.2, kernel 2.6.18.2) using emacs
> updated from trunk a few minutes ago, I get the segfault shown below.

I cannot reproduce this on a GNU/Linux machine that identifies itself
thusly:

  Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux

Can you debug this?  The place where it crashes:

  0x081a2836 in Fsystem_process_attributes (pid=17936) at process.c:7417

is this (assuming you use a recent CVS):

   if (isspace (c) || c == '\\')

I wonder how it can crash.  But then optimized builds tend to lie
about line numbers.

Re: segfault in system-process-attributes on GNU/Linux

[Bob Rogers]

   From: Andreas Schwab <schwab@suse.de>
   Date: Sat, 23 Aug 2008 20:05:29 +0200

   Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

   > Interesting.  When I evaluate:
   >
   > 	(system-process-attributes (emacs-pid))
   >
   > on my GNU/Linux system (openSUSE 10.2, kernel 2.6.18.2) using emacs
   > updated from trunk a few minutes ago, I get the segfault shown below.

   Fixed.

   Andreas.

Excellent; it works for me now.  Thanks.

   ================
   From: Eli Zaretskii <eliz@gnu.org>
   Date: Sat, 23 Aug 2008 20:40:51 +0300

   I cannot reproduce this on a GNU/Linux machine . . .

   I wonder how it can crash.  But then optimized builds tend to lie
   about line numbers.

I wondered, too, but can't seem to compile emacs with enough debugging
information; it finds the source file (at the same place you showed),
but doesn't even have debugging symbols:

	(gdb) p cmdsize
	No symbol "cmdsize" in current context.
	(gdb) 

I remember discussion of CFLAGS options for debugging, but can't find
the thread now.  I thought some writeup had been added to INSTALL.CVS or
"(emacs) Bugs", but can't find it there, either.

   In any case, any hints you may have for future debugging use would be
greatly appreciated.

					-- Bob (not a C programmer, but
					   might be able to play one on TV)

Re: segfault in system-process-attributes on GNU/Linux

[Eli Zaretskii]

> Date: Sat, 23 Aug 2008 15:12:22 -0400
> From: Bob Rogers <rogers-emacs@rgrjr.dyndns.org>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> I wondered, too, but can't seem to compile emacs with enough debugging
> information; it finds the source file (at the same place you showed),
> but doesn't even have debugging symbols:
> 
> 	(gdb) p cmdsize
> 	No symbol "cmdsize" in current context.
> 	(gdb) 
> 
> I remember discussion of CFLAGS options for debugging, but can't find
> the thread now.  I thought some writeup had been added to INSTALL.CVS or
> "(emacs) Bugs", but can't find it there, either.

The right place is etc/DEBUG.

>    In any case, any hints you may have for future debugging use would be
> greatly appreciated.

These days, if you want to debug Emacs, you need to rebuild the
sources where you want to step with -O1.

Re: segfault in system-process-attributes on GNU/Linux

[Andreas Schwab]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

> Interesting.  When I evaluate:
>
> 	(system-process-attributes (emacs-pid))
>
> on my GNU/Linux system (openSUSE 10.2, kernel 2.6.18.2) using emacs
> updated from trunk a few minutes ago, I get the segfault shown below.

Fixed.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: segfault in system-process-attributes on GNU/Linux

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Sat, 23 Aug 2008 20:05:29 +0200
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:
> 
> > Interesting.  When I evaluate:
> >
> > 	(system-process-attributes (emacs-pid))
> >
> > on my GNU/Linux system (openSUSE 10.2, kernel 2.6.18.2) using emacs
> > updated from trunk a few minutes ago, I get the segfault shown below.
> 
> Fixed.

Blush.  Sorry for my blunder.

Re: File Owner and Group ID on Windows

[Eli Zaretskii]

> Date: Fri, 22 Aug 2008 12:34:43 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Thu, Aug 21, 2008 at 18:37, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > And what about the similar code in w32_system_process_attributes? does
> > it work for the Emacs process?  If it does, perhaps we need to open
> > the current process the same way we do there, and ask for
> > PROCESS_QUERY_INFORMATION and PROCESS_VM_READ types of access.  Can
> > you check that?
> 
> (assq 'euid (system-process-attributes) (emacs-pid)) => (euid . 1006)

Good.  Could you please try writing a stand-alone program that uses
the same technique as w32_system_process_attributes to open the
current process, and see if getting the user from there does work?

Thanks.

> It's a standalone workstation (a laptop, not connected to anything
> other than the cable modem). OS is Windows XP Home Edition, SP3.

The only difference from what I have here is SP2, not SP3.  Strange.

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Fri, Aug 22, 2008 at 13:17, Eli Zaretskii <eliz@gnu.org> wrote:

> Could you please try writing a stand-alone program that uses
> the same technique as w32_system_process_attributes to open the
> current process, and see if getting the user from there does work?

Yes. I think I'll have a bit of time tonight.

 Juanma

Re: File Owner and Group ID on Windows

[Eli Zaretskii]

> Date: Fri, 22 Aug 2008 12:34:43 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> (assq 'euid (system-process-attributes) (emacs-pid)) => (euid . 1006)
> 
> > Also, do you know if this ever worked for you?  I don't think this
> > code was changed since May.
> 
> I've checked out and tested at several points around your May changes,
> and in all of them (user-uid) => 123, so I suppose it never worked.

What about Emacs 22.x: does it report something like 5 for user-uid on
that machine?  If it does, then it does work for you on that machine
in Emacs 22, and the question is what did I manage to break in what
worked before.  Could you please take a look?

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Sun, Aug 24, 2008 at 22:20, Eli Zaretskii <eliz@gnu.org> wrote:

> What about Emacs 22.x: does it report something like 5 for user-uid on
> that machine?

Yes, an EMACS_22_BASE build from today returns (user-uid) => 5.

> If it does, then it does work for you on that machine
> in Emacs 22, and the question is what did I manage to break in what
> worked before.  Could you please take a look?

Do you mean, take a look at what differs between 22.X and the trunk?

   Juanma

Re: File Owner and Group ID on Windows

[Eli Zaretskii]

> Date: Mon, 25 Aug 2008 00:52:00 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Sun, Aug 24, 2008 at 22:20, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > What about Emacs 22.x: does it report something like 5 for user-uid on
> > that machine?
> 
> Yes, an EMACS_22_BASE build from today returns (user-uid) => 5.
> 
> > If it does, then it does work for you on that machine
> > in Emacs 22, and the question is what did I manage to break in what
> > worked before.  Could you please take a look?
> 
> Do you mean, take a look at what differs between 22.X and the trunk?

Yes, sorry for being unclear.

The only change between 22.x and the current CVS trunk should be that
the value of dflt_passwd.pw_uid is computed differently from the
user's SID we extract from Emacs's process token.  But what you found
from your debugging seems to indicate that somehow one of the syscalls
we use for extracting the SID stopped working, and I don't expect any
differences there, because that code wasn't supposed to change between
22.x and the trunk.

Re: File Owner and Group ID on Windows

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Mon, 25 Aug 2008 00:52:00 +0200
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: emacs-devel@gnu.org
>>
>> On Sun, Aug 24, 2008 at 22:20, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> What about Emacs 22.x: does it report something like 5 for user-uid on
>>> that machine?
>> Yes, an EMACS_22_BASE build from today returns (user-uid) => 5.
>>
>>> If it does, then it does work for you on that machine
>>> in Emacs 22, and the question is what did I manage to break in what
>>> worked before.  Could you please take a look?
>> Do you mean, take a look at what differs between 22.X and the trunk?
> 
> Yes, sorry for being unclear.
> 
> The only change between 22.x and the current CVS trunk should be that
> the value of dflt_passwd.pw_uid is computed differently from the
> user's SID we extract from Emacs's process token.  But what you found
> from your debugging seems to indicate that somehow one of the syscalls
> we use for extracting the SID stopped working, and I don't expect any
> differences there, because that code wasn't supposed to change between
> 22.x and the trunk.


I took a quick look at the sources. I guess lookup_account_sid is
involved? In some places where it is called there is no error checking
AFAICS.

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Mon, Aug 25, 2008 at 05:07, Eli Zaretskii <eliz@gnu.org> wrote:

> The only change between 22.x and the current CVS trunk should be that
> the value of dflt_passwd.pw_uid is computed differently from the
> user's SID we extract from Emacs's process token.  But what you found
> from your debugging seems to indicate that somehow one of the syscalls
> we use for extracting the SID stopped working, and I don't expect any
> differences there, because that code wasn't supposed to change between
> 22.x and the trunk.

I don't think it has anything to do with syscalls. It's likely a
memory corruption or somesuch. The problem appears on 23.X with
optimized builds.

Specifically:

 - EMACS_22_BASE (-O2)             -- get_token_information => 1
 - trunk (-O2)                     -- get_token_information => 0
 - trunk (w32.c compiled with -O1) -- get_token_information => 1

I'm trying to pinpoint when was the problem introduced.

 Juanma

Re: File Owner and Group ID on Windows

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Mon, Aug 25, 2008 at 05:07, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> The only change between 22.x and the current CVS trunk should be that
>> the value of dflt_passwd.pw_uid is computed differently from the
>> user's SID we extract from Emacs's process token.  But what you found
>> from your debugging seems to indicate that somehow one of the syscalls
>> we use for extracting the SID stopped working, and I don't expect any
>> differences there, because that code wasn't supposed to change between
>> 22.x and the trunk.
> 
> I don't think it has anything to do with syscalls. It's likely a
> memory corruption or somesuch. The problem appears on 23.X with
> optimized builds.
> 
> Specifically:
> 
>  - EMACS_22_BASE (-O2)             -- get_token_information => 1
>  - trunk (-O2)                     -- get_token_information => 0
>  - trunk (w32.c compiled with -O1) -- get_token_information => 1
> 
> I'm trying to pinpoint when was the problem introduced.


Checking the return values from syscalls might help.

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Mon, Aug 25, 2008 at 14:48, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> Checking the return values from syscalls might help.

Sorry, I don't understand. Checking the return value of
GetTokenInformation, etc. is what I'm doing...

  Juanma

Re: File Owner and Group ID on Windows

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Mon, Aug 25, 2008 at 14:48, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>> Checking the return values from syscalls might help.
> 
> Sorry, I don't understand. Checking the return value of
> GetTokenInformation, etc. is what I'm doing...

Sorry, I did not follow the details. I am glad that you and Eli is
trying to solve this.

I just wondered if return values are always checked as the MS docs says.
As I said in a message yesterday I could not find that it was so (it
might be me missing something).

Re: File Owner and Group ID on Windows

[Juanma Barranquero]

On Mon, Aug 25, 2008 at 14:53, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> I just wondered if return values are always checked as the MS docs says.
> As I said in a message yesterday I could not find that it was so (it
> might be me missing something).

I see only two instances of lookup_account_sid's return value not
being checked, and both are in w32_system_process_attributes, so I
don't think they're related to the current bug.

  Juanma