Recursive mtime implementation questions

Recursive mtime implementation questions

[Fred Schaettgen]

Hi,

I'm trying to get started with my idea of recursive mtimes, which where 
discussed a few days ago, but I'm stuck a little. Maybe someone with some 
more knowlege about reiser4 could give me some hints?

The idea was to register each file for change monitoring and reset a special 
mtime-attribute for the file and all parent directories (recursively) if the 
watched file changes. Before this will happen the next time, a userspace 
program has to reenable mtime for each of these files again.

It's hard to discuss the problems and advantages of code that exists only in 
someone's brain, so I'm trying to implement it. I'm still quite clueless 
about the details of reiser4, but if noone else does it, I'll have no 
choice ;)

-- I have to attach a list of parent directories to each watched file, since a 
file can be hardlinked in several directories. 
This list is usually very short, but sometimes it might be quite long. How 
would I store such a list? Directly in the stat data? Or put it in a file and 
link to it from the stat data? Or is there another efficient way in reiser4 
to the all the parent directories?
It would also help to know how ACLs will be stored on disk by reiser4. Does 
reiser4 implement some sort of ACLs at all? If yes, where in the code is 
that?

-- I have to monitor the file for changes. 
The only solution I could think of was to create a new file plugin 
(watched_file), which wraps another file plugin and delegates all method 
calls to that plugin. Now where do it store the pointer to the wrapped file 
plugin in memory? If I add a new field to the reiser4_inode struct, this 
would mean that every reiser4_inode grows in size, even if it is not the 
inode of a watched file. 
In http://www.namesys.com/v4/v4.html#audit, there are some lines about an 
auditing plugin, which is not yet written. How will this work? With a 
file-plugin wrapper too or as another plugin type? Is there some code for 
that in the meantime?

-- When a file is changed, the new mtime has to be reset recursively and 
atomically at the same time.
Is it possible for reiser4 to do a number of - rarley, but still - deeply 
nested transactions?

regards
Fred

-- 
Fred Schaettgen
sch@ttgen.net

Re: Recursive mtime implementation questions

[Edward Shishkin]

Fred Schaettgen wrote:

>Hi,
>
>I'm trying to get started with my idea of recursive mtimes, which where 
>discussed a few days ago, but I'm stuck a little. Maybe someone with some 
>more knowlege about reiser4 could give me some hints?
>
>The idea was to register each file for change monitoring and reset a special 
>mtime-attribute for the file and all parent directories (recursively) if the 
>watched file changes. Before this will happen the next time, a userspace 
>program has to reenable mtime for each of these files again.
>  
>

Are you sure you need kernel support of such monitoring?

>It's hard to discuss the problems and advantages of code that exists only in 
>someone's brain, so I'm trying to implement it. I'm still quite clueless 
>about the details of reiser4, but if noone else does it, I'll have no 
>choice ;)
>
>-- I have to attach a list of parent directories to each watched file, since a 
>file can be hardlinked in several directories. 
>This list is usually very short, but sometimes it might be quite long. How 
>would I store such a list? Directly in the stat data?
>

Note that reiser4 stat-data can not occupy more then one node on leaf level

> Or put it in a file and 
>link to it from the stat data? Or is there another efficient way in reiser4 
>to the all the parent directories?
>It would also help to know how ACLs will be stored on disk by reiser4. Does 
>reiser4 implement some sort of ACLs at all? If yes, where in the code is 
>that?
>
>-- I have to monitor the file for changes. 
>The only solution I could think of was to create a new file plugin 
>(watched_file), which wraps another file plugin and delegates all method 
>calls to that plugin. Now where do it store the pointer to the wrapped file 
>plugin in memory? 
>

Currently reiser4 supports static object plugins listed in plugin/object.c
so you can add your own one and get access to it by various macro 
(file_plugin_by_id, etc..
defined in plugin.h, plugin_header.h)

>If I add a new field to the reiser4_inode struct, this 
>would mean that every reiser4_inode grows in size, even if it is not the 
>inode of a watched file.
>

There is a union (file_plugin_data) in struct reiser4_inode to keep 
features specific
for file plugins.

> 
>In http://www.namesys.com/v4/v4.html#audit, there are some lines about an 
>auditing plugin, which is not yet written. How will this work? With a 
>file-plugin wrapper too or as another plugin type?
>

The idea is that such files should be written by chaining cipher modes 
so when we
read the file, the appropriate plugin should check its integrity. This 
should be useful
for various (system) logfiles, but imho it is not the same that the 
monitoring you want.

> Is there some code for 
>that in the meantime?
>  
>

Nop, only comments ;)

Edward.

>-- When a file is changed, the new mtime has to be reset recursively and 
>atomically at the same time.
>Is it possible for reiser4 to do a number of - rarley, but still - deeply 
>nested transactions?
>
>regards
>Fred
>
>  
>

Re: Recursive mtime implementation questions

[Fred Schaettgen]

On Tuesday 11 January 2005 15:41, Edward Shishkin wrote:
> Fred Schaettgen wrote:
> >I'm trying to get started with my idea of recursive mtimes, which where
> >discussed a few days ago, but I'm stuck a little. Maybe someone with some
> >more knowlege about reiser4 could give me some hints?
> >
> >The idea was to register each file for change monitoring and reset a
> > special mtime-attribute for the file and all parent directories
> > (recursively) if the watched file changes. Before this will happen the
> > next time, a userspace program has to reenable mtime for each of these
> > files again.
>
> Are you sure you need kernel support of such monitoring?

I'm never sure, but all I know is dnotify and inotify and I don't see how I 
can reliably find changed files all over my complete harddisk with it. With 
[d|i]notify there are lots of chances where I can miss a change, be it before 
the startup of the deaemon that would be necessary, be it because the system 
is under haeay load and the change buffer runs over. And when this happens, 
all that can be done is to walk the whole file system again.
Maybe I missed another way how to do it. Do you know one?

VxFS and even NTFS seem to have file change logs to support userspace indexers 
etc. The file change log approach might be more efficient, but the recursive 
mtimes look like a simpler interface to userspace to me, with less 
security/quota related things to consider, so this feature could be easily 
accessible to any user who wishes to use it.

..
> Note that reiser4 stat-data can not occupy more then one node on leaf level

So what is the recommended way to attach some smaller piece of data to a file? 
If I write that data into a separate file or something, how do I associate 
that with the file it belongs to? By putting a key into the stat data?

> > Or put it in a file and
> >link to it from the stat data? Or is there another efficient way in
> > reiser4 to the all the parent directories?
> >It would also help to know how ACLs will be stored on disk by reiser4.
> > Does reiser4 implement some sort of ACLs at all? If yes, where in the
> > code is that?
> >
> >-- I have to monitor the file for changes.
> >The only solution I could think of was to create a new file plugin
> >(watched_file), which wraps another file plugin and delegates all method
> >calls to that plugin. Now where do it store the pointer to the wrapped
> > file plugin in memory?
..
> >If I add a new field to the reiser4_inode struct, this
> >would mean that every reiser4_inode grows in size, even if it is not the
> >inode of a watched file.
>
> There is a union (file_plugin_data) in struct reiser4_inode to keep
> features specific
> for file plugins.

I can't use that union, since my plugin would call the methods of the original 
file plugin of a file, so file_plugin_data is occupied already. I'm not sure 
if adding another field outside that union would make reiser4 perform any 
worse, but I was just hoping that this plugin can be implemented without any 
overhead at all as long as it is not used. A new feature is much more easily 
accepted if it doesn't affect you if you don't use it.

> >In http://www.namesys.com/v4/v4.html#audit, there are some lines about an
> >auditing plugin, which is not yet written. How will this work? With a
> >file-plugin wrapper too or as another plugin type?
>
> The idea is that such files should be written by chaining cipher modes
> so when we
> read the file, the appropriate plugin should check its integrity. This
> should be useful
> for various (system) logfiles, but imho it is not the same that the
> monitoring you want.

But maybe it can use the same interface as such a audit plugin. Such an audit 
plugin would have to intercept reads and writes etc. This seems to be just 
what I need. I only wonder what kind of plugin this would be - a file plugin, 
security plugin or a new type of plugin?
The file plugin wrapper-approach might work, but it is ugly to change the file 
plugin, just to be informed of changes. And I'm also not sure if this can't 
interfere with anything, like code that expects a file to be a unix_file.
Btw. if the audit plugin has to keep it's own state in memory for each file, 
where would that data go?

> > Is there some code for
> >that in the meantime?
>
> Nop, only comments ;)

Any comments are welcome ;)

regards
Fred

-- 
Fred Schaettgen
sch@ttgen.net

Re: Recursive mtime implementation questions

[Edward Shishkin]

Fred Schaettgen wrote:

>On Tuesday 11 January 2005 15:41, Edward Shishkin wrote:
>  
>
>>Fred Schaettgen wrote:
>>    
>>
>>>I'm trying to get started with my idea of recursive mtimes, which where
>>>discussed a few days ago, but I'm stuck a little. Maybe someone with some
>>>more knowlege about reiser4 could give me some hints?
>>>
>>>The idea was to register each file for change monitoring and reset a
>>>special mtime-attribute for the file and all parent directories
>>>(recursively) if the watched file changes. Before this will happen the
>>>next time, a userspace program has to reenable mtime for each of these
>>>files again.
>>>      
>>>
>>Are you sure you need kernel support of such monitoring?
>>    
>>
>
>I'm never sure, but all I know is dnotify and inotify and I don't see how I 
>can reliably find changed files all over my complete harddisk with it. With 
>[d|i]notify there are lots of chances where I can miss a change, be it before 
>the startup of the deaemon that would be necessary, be it because the system 
>is under haeay load and the change buffer runs over. And when this happens, 
>all that can be done is to walk the whole file system again.
>Maybe I missed another way how to do it. Do you know one?
>
>VxFS and even NTFS seem to have file change logs to support userspace indexers 
>etc. The file change log approach might be more efficient, but the recursive 
>mtimes look like a simpler interface to userspace to me, with less 
>security/quota related things to consider, so this feature could be easily 
>accessible to any user who wishes to use it.
>
>..
>  
>
>>Note that reiser4 stat-data can not occupy more then one node on leaf level
>>    
>>
>
>So what is the recommended way to attach some smaller piece of data to a file? 
>If I write that data into a separate file or something, how do I associate 
>that with the file it belongs to? By putting a key into the stat data?
>  
>

You may look at reiser4 symlink implementation where link is 
saved/extracted to/from
disk stat-data by ->save()/->present() methods of stat-data plugin 
(SYMLINK_STAT
extension, plugin/item/static_stat.c)

>  
>
>>>Or put it in a file and
>>>link to it from the stat data? Or is there another efficient way in
>>>reiser4 to the all the parent directories?
>>>It would also help to know how ACLs will be stored on disk by reiser4.
>>>Does reiser4 implement some sort of ACLs at all? If yes, where in the
>>>code is that?
>>>
>>>-- I have to monitor the file for changes.
>>>The only solution I could think of was to create a new file plugin
>>>(watched_file), which wraps another file plugin and delegates all method
>>>calls to that plugin. Now where do it store the pointer to the wrapped
>>>file plugin in memory?
>>>      
>>>
>..
>  
>
>>>If I add a new field to the reiser4_inode struct, this
>>>would mean that every reiser4_inode grows in size, even if it is not the
>>>inode of a watched file.
>>>      
>>>
>>There is a union (file_plugin_data) in struct reiser4_inode to keep
>>features specific
>>for file plugins.
>>    
>>
>
>I can't use that union, since my plugin would call the methods of the original 
>file plugin of a file, 
>

Let's first specify the notification interface. Should it be kernel 
messages, or
should the fs write something to /proc? (I don't have ideas)

>so file_plugin_data is occupied already. I'm not sure 
>if adding another field outside that union would make reiser4 perform any 
>worse, but I was just hoping that this plugin can be implemented without any 
>overhead at all as long as it is not used. A new feature is much more easily 
>accepted if it doesn't affect you if you don't use it.
>

This is why you need a new object plugin with its own methods.

>
>  
>
>>>In http://www.namesys.com/v4/v4.html#audit, there are some lines about an
>>>auditing plugin, which is not yet written. How will this work? With a
>>>file-plugin wrapper too or as another plugin type?
>>>      
>>>
>>The idea is that such files should be written by chaining cipher modes
>>so when we
>>read the file, the appropriate plugin should check its integrity. This
>>should be useful
>>for various (system) logfiles, but imho it is not the same that the
>>monitoring you want.
>>    
>>
>
>But maybe it can use the same interface as such a audit plugin. Such an audit 
>plugin would have to intercept reads and writes etc. This seems to be just 
>what I need. I only wonder what kind of plugin this would be - a file plugin, 
>security plugin or a new type of plugin?
>  
>

Actually I told about logfiles which are not audit plugin.  It seems the 
audit plugin is close
to the feature you want. I would create an _object_ plugin, but Hans 
might have another opinion..

Edward.

Re: Recursive mtime implementation questions

[Fred Schaettgen]

On Thursday 13 January 2005 14:15, you wrote:
> Fred Schaettgen wrote:
...
..
> >>There is a union (file_plugin_data) in struct reiser4_inode to keep
> >>features specific
> >>for file plugins.
> >
> >I can't use that union, since my plugin would call the methods of the
> > original file plugin of a file,
>
> Let's first specify the notification interface. Should it be kernel
> messages, or
> should the fs write something to /proc? (I don't have ideas)

Actually I didn't think about active notification at all. The idea is to set 
an timestamp for each monitored file, which is reset for the file itself and 
the whole path(s) upwards when the file is changed.
A userspace program which manages an index will find the newly changed files 
by looking at that timestamp in some base directory and descending into each 
subdirectory for which this timestamp is more recent than a saved timestamp 
or if the timestamp isn't set at all. On the way back, the missing timestamps 
will be updated.
So it's by design a single-shot "notification" and you would have to poll a 
single file to be able to update your stored data continously. This should be 
adequate for applications which index large parts of the file system. For 
other needs, inotify will be the better solution.

The pseudo-file interface could look like this:
file/..../watch/m_timestamp [r]
dir/..../watch/m_watch_file [w] 

m_timestamp is set for a file, when its name is written into the 
m_watch_file-attribute of one of it's parent directories.
This will also add a link to the file back to the directory, so that when the 
file is changed, the timestamp of both the file and the directory (and so on) 
are reset.
That's quite expensive, but it will happen only once per file, until the 
timestamp for a file was set again by a crawler. 

> >so file_plugin_data is occupied already. I'm not sure
> >if adding another field outside that union would make reiser4 perform any
> >worse, but I was just hoping that this plugin can be implemented without
> > any overhead at all as long as it is not used. A new feature is much more
> > easily accepted if it doesn't affect you if you don't use it.
>
> This is why you need a new object plugin with its own methods.

Ok, so creating a new file type called "watched_file" seems really the right 
way. 
This still leaves the problem where to save per-inode data for this plugin 
without having to increase the size of a reiser4_inode in general. I don't 
care much, so before anyone else complains, I'll stop thinking about it ;)

regards
Fred

-- 
Fred Schaettgen
sch@ttgen.net

Re: Recursive mtime implementation questions

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fred Schaettgen wrote:
| On Thursday 13 January 2005 14:15, you wrote:
|
|>Fred Schaettgen wrote:
|
| ...
| ..
|
|>>>There is a union (file_plugin_data) in struct reiser4_inode to keep
|>>>features specific
|>>>for file plugins.
|>>
|>>I can't use that union, since my plugin would call the methods of the
|>>original file plugin of a file,
|>
|>Let's first specify the notification interface. Should it be kernel
|>messages, or
|>should the fs write something to /proc? (I don't have ideas)
|
|
| Actually I didn't think about active notification at all. The idea is
to set
| an timestamp for each monitored file, which is reset for the file
itself and
| the whole path(s) upwards when the file is changed.
| A userspace program which manages an index will find the newly changed
files
| by looking at that timestamp in some base directory and descending
into each
| subdirectory for which this timestamp is more recent than a saved
timestamp
| or if the timestamp isn't set at all. On the way back, the missing
timestamps
| will be updated.
| So it's by design a single-shot "notification" and you would have to
poll a
| single file to be able to update your stored data continously. This
should be
| adequate for applications which index large parts of the file system. For
| other needs, inotify will be the better solution.

Can't we use inotify on that single file, or even its own attribute (as
a meta-file) that we'd otherwise have to poll?  Sorry to nitpick, I just
want to be very clear at this stage.

| The pseudo-file interface could look like this:
| file/..../watch/m_timestamp [r]
| dir/..../watch/m_watch_file [w]
|
| m_timestamp is set for a file, when its name is written into the
| m_watch_file-attribute of one of it's parent directories.
| This will also add a link to the file back to the directory, so that
when the
| file is changed, the timestamp of both the file and the directory (and
so on)
| are reset.
| That's quite expensive, but it will happen only once per file, until the
| timestamp for a file was set again by a crawler.

And what's more, you often wouldn't have to travel farther up the tree
than the parent directory, if that parent is common to a lot of changing
files.

|>>so file_plugin_data is occupied already. I'm not sure
|>>if adding another field outside that union would make reiser4 perform any
|>>worse, but I was just hoping that this plugin can be implemented without
|>>any overhead at all as long as it is not used. A new feature is much more
|>>easily accepted if it doesn't affect you if you don't use it.
|>
|>This is why you need a new object plugin with its own methods.
|
|
| Ok, so creating a new file type called "watched_file" seems really the
right
| way.
| This still leaves the problem where to save per-inode data for this
plugin
| without having to increase the size of a reiser4_inode in general. I
don't
| care much, so before anyone else complains, I'll stop thinking about it ;)

The trick is converting normal files to watched_files.

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQecKfHgHNmZLgCUhAQLLnxAAlgKzroTX0MTy/VVOLKr+4l+34/2g32AB
Rg9+kQWIeVpGfzyLpSy0DhO/0Mt01/9zDkvgYRGwgGhfw496BFPtkF/YvmlcFPbs
Txm5x/HiYjHinb5xah/Eq3lkTov/Y4eEyXvPJWk74MOS3MF/NAB8zuQ6ZLKf5LDT
w3eVxdMA/ubbpL6JmcCImeueJEdZ8ZXf+oI3AsQVmPW4gbaIZkCXxUem574BoVQc
tT6F7S9dmETw6M+VlSj0txWWE8iVwJ43QKErUSIpGgXVxSvE6pB97HrgD0oAwBrz
G1v+6ODRaW20zYdAbxH619Moq8KsubucWcwxSsHCK5mGSrwFqK1ry0w6CqxCXgxT
OiyNzPlW2WWZumRqmpI250EyS7JP7jdI+/xQFTB7OMr+9Pbveplrxm7BvRNwVKjB
y1G8F/hUDGaL0Rfb8ogG9tLMeNrVUpOOJ9gWBqnw7WglTxDUgmanNADzK1gEt1/E
HHh3tJDqFV0JR+zb+MhZt2OLJ9goGDEAva4Ckc8IGahkya13W/lj2eAP4c5jdi3O
OHW1UvHq4qBOlQyUQzHTjZVJqkb66e8OWUwb7+BTrXcbagNgOameDVhipEjZMn4+
LdrGjySWu4YFX/u4JAiyP0G1daiAqZ7bQ5amBh3JE0K0auRiConI0//iDwdXq+4e
O8piUEsBnQ8=
=Yb7h
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQecKqXgHNmZLgCUhAQKxHQ/9Fb7IPLnqcHuhNK01djVpDLfc/7L7TRVG
4dU7cG27VDGrqbRjXOIdtjwBSxcKO0+pQHcGccMpd7+gNu6Z+xVzcivj0qBBhrcY
wIU4lPM6r2Izbj73b5qEOAh/UtX1+cfyJ5gihDl69sIlePZF0lgmYhTxvz9L24Sx
QFvw76Ei1UvSncP7QIkn9znZiPUTTi57Xs9u5vX5HI9tVQWQgvPxwbOeN4T25RC/
IY6kd507oGgz3kRKcd5ji3UDXcgFcdvaFWn7gWd3uGSqK44KujX5D3NDNs3P18JM
9D0xGUyUgd/Nuxokb+qmGTmAVTaUYOoWSMOUYFpt3mlwDgZZ5+dH4pIA2cH3qCpe
uQZVi3n7fPPpE+Q9BrgaPn+vmkZ9yoqEt5Zzlp58AtlXmtNnmuBOYH7BO3iXyz8U
wGPLNAsFpTByA1p08QVRyuBkzCG9jw1a7dlwpMrsoaOH7k/2Yw/vhW1B/CgyUnAP
aQCRYIGkekUc6XSM0uhaCDyF3wMTsn0Ec1aI9ZzObfA0IOh0is9vzBc6cXRAvHcs
sbY0DBVD7vhLNwvEfrN6JYKrvxdfJ+n89Gkd6rn2Jtc7n2m3Fllq3S2Cx+ch87L6
xfRYZGM79HOJB5C7a2HZT4vNWNDsdfXAn3gffsFSSHq558Srz8K27Or3MRCf9Ec5
tI201Z6LZo4=
=f3Th
-----END PGP SIGNATURE-----

Re: Recursive mtime implementation questions

[Edward Shishkin]

Fred Schaettgen wrote:

>On Thursday 13 January 2005 14:15, you wrote:
>  
>
>>Fred Schaettgen wrote:
>>    
>>
>...
>..
>  
>
>>>>There is a union (file_plugin_data) in struct reiser4_inode to keep
>>>>features specific
>>>>for file plugins.
>>>>        
>>>>
>>>I can't use that union, since my plugin would call the methods of the
>>>original file plugin of a file,
>>>      
>>>
>>Let's first specify the notification interface. Should it be kernel
>>messages, or
>>should the fs write something to /proc? (I don't have ideas)
>>    
>>
>
>  
>

Hi, sorry for long silence

>Actually I didn't think about active notification at all. The idea is to set 
>an timestamp for each monitored file, which is reset for the file itself and 
>the whole path(s) upwards when the file is changed.
>A userspace program which manages an index will find the newly changed files 
>by looking at that timestamp in some base directory and descending into each 
>subdirectory for which this timestamp is more recent than a saved timestamp 
>or if the timestamp isn't set at all. On the way back, the missing timestamps 
>will be updated.
>So it's by design a single-shot "notification" and you would have to poll a 
>single file to be able to update your stored data continously. This should be 
>adequate for applications which index large parts of the file system. For 
>other needs, inotify will be the better solution.
>
>The pseudo-file interface could look like this:
>file/..../watch/m_timestamp [r]
>dir/..../watch/m_watch_file [w] 
>
>m_timestamp is set for a file, when its name is written into the 
>m_watch_file-attribute of one of it's parent directories.
>This will also add a link to the file back to the directory, so that when the 
>file is changed, the timestamp of both the file and the directory (and so on) 
>are reset.
>  
>

So what is the values of reset timestamps for all the objects in the path?

>That's quite expensive, but it will happen only once per file, until the 
>timestamp for a file was set again by a crawler. 
>
>  
>
>>>so file_plugin_data is occupied already. I'm not sure
>>>if adding another field outside that union would make reiser4 perform any
>>>worse, but I was just hoping that this plugin can be implemented without
>>>any overhead at all as long as it is not used. A new feature is much more
>>>easily accepted if it doesn't affect you if you don't use it.
>>>      
>>>
>>This is why you need a new object plugin with its own methods.
>>    
>>
>
>Ok, so creating a new file type called "watched_file" seems really the right 
>way. 
>This still leaves the problem where to save per-inode data for this plugin 
>without having to increase the size of a reiser4_inode in general. I don't 
>care much, so before anyone else complains, I'll stop thinking about it ;)
>  
>

It seems you just need one pointer to in-memory slot of link names (the 
number of names
is i_nlink). Disk stat-data should be updated by appropriate link 
operations so its size can
be changed. This can be implemented via killing old stat-data and 
creating a new one.
 There is some methods of the reiser4 object plugin which may be 
responsible for this update:
->can_add_link() should check if there is enough place in stat-data to 
add a new name.
->add_link(), ->rem_link() besides inc/dec of i_nlink should update 
inode's in-memory slot
and kill old/create new stat-data. After killing an old stat-data set a 
flag REISER4_NO_SD,
so write_sd_by_inode_common() will create a new one. Killing stat-data 
is unsafe operation
and should be protected (see using of safe_link interface in 
common_object_delete()).

Edward.

>regards
>Fred
>
>  
>