Changed behavior of ::SHFileOperation() in Vista

[David Wilkinson]

Suppose I use ::SHFileOperation() with

SHFILEOPSTRUCT::eFunc = FO_COPY
SHFILEOPSTRUCT::fFlags = FOF_FILESONLY | FOF_SILENT

then on Windows XP (and earlier I would imagine), the effect of the
FOF_SILENT flag is to suppress the progress dialog box (as documented).
It does not suppress the dialog that asks if you want to overwrite
pre-existing files. However, on Vista, this flag causes the call to fail
silently if the copying operation would overwrite pre-existing files.
This would seem to have the potential to destroy a lot of existing
programs, and is contrary to the documentation on ::SHFileOperation().

David Wilkinson

[Tom Serface]

You might want to post this as a bug to the Vista site if you haven't
already done so. However, maybe they consider this a "fix" for a problem
that was in XP.

Tom

"David Wilkinson" <no-r...@effisols.com> wrote in message
news:enHkM9z2...@TK2MSFTNGP05.phx.gbl...

[David Lowndes]

David,

It may help to highlight this issue (I've not checked it myself) if
you knock up a simple application that reproduces it simply. If you
then submit a bug report against Vista with the source code and built
program, one of the MS testers will be easily able to reproduce it -
and check it against XP.

BTW, which build of Vista have you checked this against?

Dave Lowndes

[David Wilkinson]

Tom Serface wrote:

> You might want to post this as a bug to the Vista site if you haven't
> already done so. However, maybe they consider this a "fix" for a problem
> that was in XP.
>

[snip]

Tom:

I will certainly be reporting this using the Microsoft beta client, just
as I have reported a lot of other problems in the past (most still
present in Release Candidate 1). But the absence of feedback, coupled
with lack of access to the Vista Beta Connect site, makes this a very
frustrating experience.

David

[David Wilkinson]

David Lowndes wrote:

[snip]

>
> David,
>
> It may help to highlight this issue (I've not checked it myself) if
> you knock up a simple application that reproduces it simply. If you
> then submit a bug report against Vista with the source code and built
> program, one of the MS testers will be easily able to reproduce it -
> and check it against XP.
>
> BTW, which build of Vista have you checked this against?
>
> Dave Lowndes

Hi Dave:

This and most of my other recent testing has been done on

Vista Beta Ultimate RC1 x64

I will be reporting this problem, but as I indicated in my reply to Tom
Serface I find the error reporting situation for Vista beta extremely
frustrating.

Will try to find time to put together a repro example.

David Wilkinson

[David Lowndes]

>I will be reporting this problem, but as I indicated in my reply to Tom
>Serface I find the error reporting situation for Vista beta extremely
>frustrating.

I understand ;)

Dave

[Tom Serface]

I'm not sure whether they are going to see this as a bug or a repair.
Either way it's worth noting as it could be a "breaking item" at least.

Tom

"David Wilkinson" <no-r...@effisols.com> wrote in message

news:OZGLyV92...@TK2MSFTNGP03.phx.gbl...

[Tom Serface]

I got indication today that MSFT may be improving the bug reporting
mechanisms in the future. I'm sure many of us will see that as a huge step.

Tom

"David Lowndes" <Dav...@example.invalid> wrote in message
news:4hsvg29jnv0i9nnad...@4ax.com...

[David Lowndes]

>I got indication today that MSFT may be improving the bug reporting
>mechanisms in the future. I'm sure many of us will see that as a huge step.

You filled in the survey I take it :)

I find the problem isn't so much the bug reporting tool - it's the
lack of feedback and the feeling that no-one's bothered trying to
reproduce your bug that often results that is so irritating. I should
add that my comments here mostly apply to the OS betas - the VS
feedback on bugs that I get is mostly excellent.

Dave

[David Wilkinson]

David Lowndes wrote:

Dave:

Yes, I submitted my first reports many weeks ago on the July CTP version
(build 5472). I have never received any feedback, and almost all the
bugs I reported are still there in RC1.

David Wilkinson

[Tom Serface]

Yeah, I can imagine the task is overwhelming. I have recieved a few
replies, but mostly they have been automated replies when someone updates
the status. I can't imagine trying to manage a beta for a product that
huge... I hope the new software helps them do a better job of it.

Tom

"David Lowndes" <Dav...@example.invalid> wrote in message

news:5bi0h21rdfevpdakn...@4ax.com...

[David Wilkinson]

Tom Serface wrote:

> Yeah, I can imagine the task is overwhelming. I have recieved a few
> replies, but mostly they have been automated replies when someone updates
> the status. I can't imagine trying to manage a beta for a product that
> huge... I hope the new software helps them do a better job of it.
>
> Tom
>

Tom:

Maybe it will, but the current situation tempts me to agree with those
who maintain the that the public Vista beta program was just a publicity
stunt, rather than a genuine attempt to get feedback on the OS.

David Wilkinson

[Tom Serface]

There's not doubt in my mind that some of it is publicty. Microsoft knows
how to market better than any other company I've ever seen. When Windows 95
came out people were lined up to buy it and it made the evening news. I'm
guessing they are looking for a repeat performance, however I do think they
are honestly trying to educate users and trying to make the OS as stable as
possible before releasing it and pulling back on XP. It does contain some
pretty big paradigm shifts.

Tom

"David Wilkinson" <no-r...@effisols.com> wrote in message

news:OejMhmD3...@TK2MSFTNGP04.phx.gbl...

[iatethew...@gmail.com]

I just tried this via c++ on the RC1 build of Vista x86. It does not
silently fail. I get the conflict resolution dialog asking which file
in the destination I want to keep. Below are the source/destination
paths passed to SHFILEOPSTRUCT.

src = c:\folder1\*
dest = c:\folder2\

Both folders have the same files/folders.

Was there a step I am missing?

[David Wilkinson]

iatethew...@gmail.com wrote:

> I just tried this via c++ on the RC1 build of Vista x86. It does not
> silently fail. I get the conflict resolution dialog asking which file
> in the destination I want to keep. Below are the source/destination
> paths passed to SHFILEOPSTRUCT.
>
> src = c:\folder1\*
> dest = c:\folder2\
>
> Both folders have the same files/folders.
>
> Was there a step I am missing?
>

[snip]

Did you use the FOF_SILENT flag? It works if you do not use this flag,
but then you get the progress dialog. In XP, this flag only suppresses
the progress dialog, not the conflict resolution, in agreement with the
documentation on SHFILEOPSTRUCT.

David Wilkinson

[iatethew...@gmail.com]

> Did you use the FOF_SILENT flag? It works if you do not use this flag,
> but then you get the progress dialog. In XP, this flag only suppresses
> the progress dialog, not the conflict resolution, in agreement with the
> documentation on SHFILEOPSTRUCT.
>
> David Wilkinson

Correct. I am passing FOF_SILENT | FOF_FILESONLY for a FO_COPY
operation.

The 2 directories have the same contents a file and and empty folder.

Src = c:\test1\*
dest = c:\test2\

I get the confirm replace dialog for the file - are you not seeing
this? Can you try with the single file and single folder both the
source and destination to see if it is reproducible? If not, it may be
something special about the files/folders you are copying that is
causing this (ACLs, file attributes, UAC elevation, user rights, etc).

Please specify more details.

[David Wilkinson]

iatethew...@gmail.com wrote:

iatethewholething:

Thanks for looking at this. Few developers seems very interested in
investigating Vista at this time. Come to that, MS does not seem that
interested in fixing bugs in Vista, to judge by the level of feedback
from filling out error reports using the Microsoft Beta Client.

I have modified my example slightly:

Vista RC1 x86 (I saw this on x64 also)
Source: C:\Program Files\MyCompany\MyApp\Sample Files\*
Destination: C:\Users\David\Documents\MyApp\Sample Files
Source and destination both have a file and a folder (with same names)
SHFILEOPSTRUCT::wFunc = FO_COPY

SHFILEOPSTRUCT::fFlags = FOF_FILESONLY | FOF_SILENT

App is unicode app compiled with VC6 and Feb 2003 PSDK.

What is possibly different from you?

0. Program is running using a default "semi-adminstrator" account. But
it fails in the same way if I do "Run as adminsitrator." Also if I run
it in XP SP2 compatibilty mode.

1. Source is a UAC location (that's why I am doing the copy!). But when
the destination folder is empty, the call works correctly and silently,
as it should. So I don't think UAC is an issue here.

2. My source is double null-terminated, the destination not.

3. My paths have spaces in them

4. Mine is a Unicode compiled app (is yours?)

5. Mine is compiled with VC6 (this should not matter, right?).

Is anybody else interested in looking at this? If this is a problem in
Vista, it is a very serious problem, IMHO.

David Wilkinson

[David Wilkinson]

iatethewholething:

I still get this problem in the latest Vista build 5728 available from

http://download.windowsvista.com/preview/rc1/en/download-5728.htm

David Wilkinson

[Christopher Davis [MSFT]]

Replying from my work account now :). I am iatethewholething and am also a
tester on the Windows Shell team. Believe me - we do scour the newsgroups
for issues with our APIs.

I created the same paths as you have below via an elevated administrator
account and executed shfileoperation without any issues. I received the
Copy File dialog asking which file I wanted to keep in the destination (or
both). You said that the destination path is not double null terminated.
Both paths should be double null terminated.

Most of the time when I am trying to reproduce a bug in SHFileOperation I am
using a manual tool I wrote to call the api with the inputted flags/paths.
I'll try to make this available on http://www.shellrevealed.com in the
download section so you can try it out in the next few days (once I get
approval :)). The website is only a couple of weeks old but is a great place
to give feedback directly to the Windows Shell team members.

In the meantime, can you post some code around where you construct the paths
and pass them to the SHFILEOPSTRUCT for the operation? Also a dir cmd dump
of the contents of the source and destination would help.

To recap - I cannot reproduce what you are seeing on the publicly available
RC1 build or recent RTM builds of Vista on x86/x64.

Thanks,
Christopher Davis [MS]

[David Wilkinson]

Christopher Davis [MSFT] wrote:
> Replying from my work account now :). I am iatethewholething and am
> also a tester on the Windows Shell team. Believe me - we do scour the
> newsgroups for issues with our APIs.
>
> I created the same paths as you have below via an elevated administrator
> account and executed shfileoperation without any issues. I received the
> Copy File dialog asking which file I wanted to keep in the destination
> (or both). You said that the destination path is not double null
> terminated. Both paths should be double null terminated.
>
> Most of the time when I am trying to reproduce a bug in SHFileOperation
> I am using a manual tool I wrote to call the api with the inputted
> flags/paths. I'll try to make this available on
> http://www.shellrevealed.com in the download section so you can try it
> out in the next few days (once I get approval :)). The website is only a
> couple of weeks old but is a great place to give feedback directly to
> the Windows Shell team members.
>
> In the meantime, can you post some code around where you construct the
> paths and pass them to the SHFILEOPSTRUCT for the operation? Also a dir
> cmd dump of the contents of the source and destination would help.
>
> To recap - I cannot reproduce what you are seeing on the publicly
> available RC1 build or recent RTM builds of Vista on x86/x64.
>
> Thanks,
> Christopher Davis [MS]
>

[snip]

Chris:

Thanks a lot for replying in your official capacity! I have to say I
have been extremely frustrated by the lack of feedback on Vista bug
reports (even as an MVP), and also by the number of seemingly
fundamental bugs that persisted into Vista RC1. But I am happy to report
that the latest build 5728 did rectify a number of my concerns (still no
feedback, though, except you). And I am sure we will now sort out this
SHFileOperation problem.

Unfortunately I am vacation this week, and do not have access to my
Vista test machine. So, let me just send you the method I use to
generate this error (resisting the temptation to clean it up). There are
some things in it that refer to my application, but you will be able to
see how I used SHFileOperation (perhaps incorrectly!).

Just a couple of notes:

1. The purpose of this method is to allow the user to obtain a fresh
copy of my Sample documents from the Program Files folder where they
were installed. You should not need to be elevated to perform this
operation; you should not even need to be an administrator. In fact the
whole point of what I am currently doing/testing with my app is to make
sure that it will run as a standard user on NT/2000/XP/Vista, and
without Vista virtualization (an abomination, IMHO). But the actual test
I ran was on an ordinary (default) administrator account without elevation.

2. I see this problem on Vista RC1, and on the latest 5728 build.

3. The code with FOF_SILENT fails on Vista only the second time it is
called (with the same destination), because only then is the conflict
resolution required. The first time it works fine. And it works fine
without the FOF_SILENT flag.

4. I had thought the destination location only had to be double
null-terminated if the FOF_MULTIDESTFILES is set. Is this wrong? Could
this be the source of the problem?

5. My code works as intended on XP SP2 (using default account with
administrator rights).

6. Typical paths (on Vista) resulting from my code are

Source: C:\Program Files\MyCompany\MyApp\Sample Files\*
Destination: C:\Users\David\Documents\MyApp\Sample Files

Thanks again! It would be great to use your tool, but I can't do it till
next week.

David Wilkinson

[David Wilkinson]

[snip]

Chris:

My laptop newsreader (Mozilla-based) was set to place attachments
inline. Sending again as proper attachment (hopefully).

Thanks for your help.

David Wilkinson

[Christopher Davis [MSFT]]

Nothing jumps out at me in the code. When you get a chance, try with the
destination buffer double-null terminated. The internals of the
SHFileOperation has changed greatly in Vista since previous releases. It
could be that you were able to get away with this before but not now.

I'll play around with the source you provided today and see if it makes a
difference since you are on vacation.

Thanks for the reply, David.

Christopher Davis [MSFT]

"David Wilkinson" <no-r...@effisols.com> wrote in message

news:ezYoMXY4...@TK2MSFTNGP05.phx.gbl...

[David Wilkinson]

Christopher Davis [MSFT] wrote:
> Nothing jumps out at me in the code. When you get a chance, try with
> the destination buffer double-null terminated. The internals of the
> SHFileOperation has changed greatly in Vista since previous releases.
> It could be that you were able to get away with this before but not now.
>
> I'll play around with the source you provided today and see if it makes
> a difference since you are on vacation.
>
> Thanks for the reply, David.
>
> Christopher Davis [MSFT]
>

[snip]

Christopher:

It will be next week before I can get to my Vista test machine, but I
will try double null-terminating the destination folder. However I think
it is generally believed that this is not necessary for a single
destination folder, and therefore this change (if required for Vista)
will (unnecessarily) break a number of existing apps. And it is hard to
see why this would matter only when FOF_SILENT is specified.

I can believe that the code for the SHFileOperation has changed
considerably, because the visual appearance of the dialog is much
different from XP and earlier.

Thanks again,

David Wilkinson
Visual C++ MVP

[Christopher Davis [MSFT]]

Thanks David. I've debugged the issue and this appears to be a valid bug in
Vista. It only seems to materialize when you specify FOF_SILENT and the hwnd
member of the SHFILEOPSTRUCT is NULL. I'll follow up with any further
progress.

Christopher Davis [MSFT]

"David Wilkinson" <no-r...@effisols.com> wrote in message

news:emg2v5a4...@TK2MSFTNGP06.phx.gbl...

[David Wilkinson]

Christopher Davis [MSFT] wrote:
> Thanks David. I've debugged the issue and this appears to be a valid
> bug in Vista. It only seems to materialize when you specify FOF_SILENT
> and the hwnd member of the SHFILEOPSTRUCT is NULL. I'll follow up with
> any further progress.
>

[snip]

Thanks Christopher!

If you are interested in other possible developer-related bugs in Vista,
I have put up a web page at

http://www.effisols.com/vista/

Several of the issues described therein were resolved in build 5728, but
a few remain, in particular two where Vista incorrectly reports that a
setup or uninstall failed. Another is that Vista does not appear to
virtualize the HKCR registry hive, despite the fact that writing to HKCR
is normally equivalent to writing to HKLM; this causes failure of the
MFC CWinApp::RegisterShellFileTypes() method.

[Christopher Davis [MSFT]]

Thanks David. I looked these up and there are customer bugs tracking your
issues - so they are being looked into.

Christopher Davis [MSFT]

"David Wilkinson" <no-r...@effisols.com> wrote in message

news:usPj4gj4...@TK2MSFTNGP04.phx.gbl...

[David Wilkinson]

Christopher Davis [MSFT] wrote:

> Thanks David. I've debugged the issue and this appears to be a valid
> bug in Vista. It only seems to materialize when you specify FOF_SILENT
> and the hwnd member of the SHFILEOPSTRUCT is NULL. I'll follow up with
> any further progress.
>

[snip]

Hi Chris:

I have verified that if I set the hwnd member of SHFILEOPTSTRUCT to a
non-NULL value (the main window of my app) then this FOF_SILENT Vista
problem does not occur. Looking at the documentation I do not see having
a NULL hwnd mentioned as being a possibility (unlike some other Windows
API's), so perhaps my code was always wrong? But it always worked before
Vista.

I wrote this code a long time ago, so I do not remember why I did not
set the hwnd member. The docs say

hwnd
Window handle to the dialog box to display information about the status
of the file operation.

which perhaps confused me. What "dialog box"? Why not just "window"?
Also, I can imagine a situation where I might want to use
SHFileOperation() before my main Window is created, in which case I
would want to be able to have a NULL hwnd. If it worked before Vista
with NULL hwnd, I think it should in Vista. And I think the
documentation should be changed.

Another thing about the documentation. I see

FOF_FILESONLY
Perform the operation on files only if a wildcard file name (*.*) is
specified.

Isn't the specification *.* wrong here? Surely this applies to * also
(or any specification containing a wild card, such as *.doc).

I also see that the docs are pretty unambiguous that both pFrom and pTo
should be double null-terminated (even without FOF_MULTIDESTFILES), so I
guess that my code was technically wrong here also (though this does not
seem to have been the problem).

[BTW, all these comments about the docs refer to the Feb 2003 PSDK (the
one I use). If they have already been changed, my apologies.]

I have to say that I do not like the new Vista conflict resolution dialog:

Previously, I could just click "Yes to all" to overwrite all the
existing files. Now I have to BOTH select "Copy and replace" AND notice
and select a small check box at the bottom in order to repeat for all
the files. Two steps instead of one. Also, suppose I have 12 files that
will be overwritten (as I happen to). Then the check box says "Do this
for next 11 conflicts". The "11" initially confused me (even as the
author of the application!). Perhaps this number would be appropriate if
the user had manually initiated this action from Explorer, but when
activated from an application I think it will be confusing. I would
prefer "Do this for all conflicts".

Anyway, thanks for looking into this.

[David Wilkinson]

Christopher Davis [MSFT] wrote:

> Thanks David. I looked these up and there are customer bugs tracking
> your issues - so they are being looked into.
>
> Christopher Davis [MSFT]
>
>
> "David Wilkinson" <no-r...@effisols.com> wrote in message
> news:usPj4gj4...@TK2MSFTNGP04.phx.gbl...
>
>> Christopher Davis [MSFT] wrote:
>>
>>> Thanks David. I've debugged the issue and this appears to be a valid
>>> bug in Vista. It only seems to materialize when you specify
>>> FOF_SILENT and the hwnd member of the SHFILEOPSTRUCT is NULL. I'll
>>> follow up with any further progress.
>>>
>> [snip]
>>
>> Thanks Christopher!
>>
>> If you are interested in other possible developer-related bugs in
>> Vista, I have put up a web page at
>>
>> http://www.effisols.com/vista/
>>
>> Several of the issues described therein were resolved in build 5728,
>> but a few remain, in particular two where Vista incorrectly reports
>> that a setup or uninstall failed. Another is that Vista does not
>> appear to virtualize the HKCR registry hive, despite the fact that
>> writing to HKCR is normally equivalent to writing to HKLM; this causes
>> failure of the MFC CWinApp::RegisterShellFileTypes() method.
>>
>> David Wilkinson
>> Visual C++ MVP
>
>

Thanks, Chris.

I have just noticed that the error "Hidden message box on uninstall"
which I listed as fixed in build 5728 is only fixed in the x86 version.
In x64 the problem remains. I will file this with the Microsoft beta
client (unrewarding though it is).

I have to say IMHO that the problems described on my web page related to
erroneous reports that an application did not install or uninstall
correctly are extremely serious, and will create a negative experience
for many users. The example given in MSDN is that of Microsoft
Intellitype (a Microsoft application, no less!) that was hard wired only
to install under Windows 2000 or XP. Such a setup program deserves to
fail, and should not be a reason to create a negative experience for
users of correctly written setups that will run on any version of
Windows. I think using lack of change in the program database to
indicate failure is a fundamentally flawed idea, and the ability to turn
this feature off using a manifest will not help the great number of
legacy installations that will be negatively impacted (ironically, these
are the ones that are supposed to "helped" by this feature).

I would welcome the opportunity to discuss these issues with the team
involved with this aspect of Program Compatibility.

[David Wilkinson]

Christopher Davis [MSFT] wrote:

> Thanks David. I've debugged the issue and this appears to be a valid
> bug in Vista. It only seems to materialize when you specify FOF_SILENT
> and the hwnd member of the SHFILEOPSTRUCT is NULL. I'll follow up with
> any further progress.
>
> Christopher Davis [MSFT]
>
> "David Wilkinson" <no-r...@effisols.com> wrote in message
> news:emg2v5a4...@TK2MSFTNGP06.phx.gbl...
>

[snip]

Chris:

Another thing I've just noticed about SHFileOperation() is that if the
user selects Cancel in the conflict dialog at any stage then it returns
non-zero, indicating failure. It seems this was always the behavior, at
least in XP, and it still is in Vista. I'm sure this is not going to be
changed, but it is not what I would have expected. This should be noted
in the documentation, IMHO.

David Wilkinson

[iatethew...@gmail.com]

Hey David - my work newsgroup account seems to be having issues. :(

I verified that the original issue is now fixed. You should see the
same behavior in the RC2 and later builds of Vista as you did with XP
for SHFileOperation.

I'll work on the documentation issues which you should see a couple of
months after Vista ships which is when the next rev of the MSDN docs go
up.

Thanks for you help!

Christopher Davis [MSFT]

[David Wilkinson]

iatethew...@gmail.com wrote:

> Hey David - my work newsgroup account seems to be having issues. :(
>
> I verified that the original issue is now fixed. You should see the
> same behavior in the RC2 and later builds of Vista as you did with XP
> for SHFileOperation.
>

[snip]

Thanks, Chris, but I do not see this as being fixed in RC2, either x86
or x64 (clean installs).

David Wilkinson

[Christopher Davis [MSFT]]

My mistake. The fix did not make it in time for the RC2 build. It is
currently in the RTM builds, though.

Chris

"David Wilkinson" <no-r...@effisols.com> wrote in message

news:eyGEkV96...@TK2MSFTNGP04.phx.gbl...

[David Wilkinson]

Christopher Davis [MSFT] wrote:

Chris:

Good to hear! But I'll be checking ...

Thanks for all your help. With all the effort I have gone to reporting
Vista bugs, this is the only personal response I have gotten. Not
allowing people who file reports to see the bug logs on Connect is
absolutely crazy, IMHO. Especially for MVP's.

David Wilkinson

David Wilkinson

[raj...@gmail.com]

Chris:

Just verified in RTM, the SHFileOperation() API still fails when NULL
is passed as the window handle to delete contents of entire folder
recursively. Is there a work around for this.

Can some one in VISTA team take a look at this and provide a possible
solution. This API worked fine without issues in XP and Win2003. I was
hoping for the same in Vista.

Thanks
Raj

[David Wilkinson]

raj...@gmail.com wrote:

> Chris:
>
> Just verified in RTM, the SHFileOperation() API still fails when NULL
> is passed as the window handle to delete contents of entire folder
> recursively. Is there a work around for this.
>
> Can some one in VISTA team take a look at this and provide a possible
> solution. This API worked fine without issues in XP and Win2003. I was
> hoping for the same in Vista.

Raj:

Are you sure? The issue seems to be fixed for me in RTM (thanks Chris!).

But I am not deleting. I am just copying files into a folder that I have
made sure exists (using CreateDirectory()). My actual copying code is as
shown in an earlier post.

I have to say, though, that when I looked at teh documentation, it did
not say that passing NULL window handle was allowed. But, as you say, it
always worked on XP (and earlier).

David Wilkinson

[raj...@gmail.com]

David,

Yes my delete does not work even with providing a (valid) parent window
handle in RTM!. Now I am doing manual deletion recursively. By using
the SHFileOperation() I could have avoided the recursion.

Keep me posted if you find any working solution for this.

I am happy for you that your code worked.

Thanks
Raj

[iatethew...@gmail.com]

Hi Raj,

Can you add some details about how SHFileOperation is failing for you.

- Exact paths passed to SHFileOperation
- Details of the contents of the folders
- Are the items being sent to the recycle bin or being permanently
deleted?
- Are your running your code as an elevated user/admin?
- What is the error code returned from SHFileOperation?
- What flags are you passing into the SHFILEOPSTRUCT?
- What UI appears during the operation if any? How are you responding
to it?

Thanks,
Christopher Davis