Simply does not work with Outlook 2016 ProPlus #12
Comments
|
Hello,
The Enterprise edition has some extra features but I dont think that the version is related to your issues. Greetings, |
|
Thanks for your quick response. [Note: I am a programmer, so I know a
little more about this stuff than the average user.] I tried to attach a
ZIP archive file with screenshots (each one is numbered for correct sorting
in chronological sequence), but it failed at the GitHub server because it
was too large. Can you suggest any way for me to get a 4 MiB ZIP archive
file to you?
In the meantime, here are my responses to your comments [by item number as
you listed them]. They won't make much sense until you can see the screen
shots and the JPG image file names (which describe what I wanted to show).
1. Neither Process Explorer NOR TaskInfo can locate an open handle for any
of the PST files (all of which have a similar file name [for their initial
6 characters]). The behavior I have reported occurs regardless of whether
or not Skype for Business is [still] running, was ever running, or was
never, ever even started on the PC (since the last reboot).
2. Neither Process Explorer NOR TaskInfo can locate an open handle for the
OST file. Yes, there is an error message (see attached screenshot #1). I
know backing up the OST file is useless, but I had (eventually) added it to
the list of files to be backed up just to see if doing so altered the
behavior of the add-in. It is not a problem for me to leave it in the list
of files to be backed up since the program decides rather quickly that it
can't get the file lock. But I will take it out for all future
tests. Additional note: At the end of backup processing by the add-in, it
"stops" or "hangs" and no more activity takes place, and the window does
not close (although it CAN _BE_ closed [using the X]). See the attached
screenshot #13. It will stay displayed for hours until it is closed.
Terminating the process will also, of course, remove the window. It appears
that the process just goes into a wait, and no processor time is consumed,
and no PST files (that is supposedly opened and copied) remain open. Is
this normal behavior? I would not expect that to happen. But if it's normal
behavior, I can live with it.
3. You are correct. In my many, many tests, I ended up making and keeping a
lot of copies around in different folders. I *did* compare the wrong files.
Comparing the right files shows that they ARE bit-for-bit identical.
4. See the attached screenshots for message(s). This behavior occurs
regardless of the target of the copy (a local folder or a file server
folder). Screenshots #1 thru #12 represent captures I made during
processing. Screenshot #13 I discuss below.
5.A. First, I made several runs timing the copying of ALL of the PST files
[the total file size of which is 16.2 GB] using various facilities other
than your add-in. This should give you some idea of how fast a file copy
here on my LAN can proceed. The two test file servers, Y and Z, are on the
same Ethernet switch, actually in the same room here with the PC on which I
am testing runs Outlook 2016 ProPlus.
5.A.1. Copying all PST files from a local folder to another local folder
(on the same physical SSD) using the Beyond Compare utility takes 8 minutes
39 seconds (see attached screenshot #14).
5.A.2. Copying all PST files from a local folder to another local folder
(on the same physical SSD) using Windows Command Prompt COPY takes 4
minutes 19 seconds (see attached screenshot #15).
5.A.3. Copying all PST files from a local folder to a file server folder on
Server Y (via a gigabit LAN connection) using the Beyond Compare utility
takes 3 minutes 7 seconds (see attached screenshot #16).
5.A.4. Copying all PST files from a local folder to a file server folder on
Server Y (via a gigabit LAN connection) using Windows Command Prompt COPY
takes 2 minutes 45 seconds (see attached screenshot #17).
5.A.5. Copying all PST files from a local folder to a file server folder on
Server Z (via a gigabit LAN connection) using the Beyond Compare utility
takes 3 minutes 28 seconds (see attached screenshot #18).
5.A.6. Copying all PST files from a local folder to a file server folder on
Server Z (via a gigabit LAN connection) using Windows Command Prompt COPY
takes 3 minutes 9 seconds (see attached screenshot #19).
5.A.7. The fastest target and file copy tool are a folder on file server Y
and Windows Command Prompt COPY commands. I have no idea why Beyond Compare
is slower than a COPY command in a Windows Command Prompt, but that appears
to be the case regardless of target folder location. In any event, I
configured the backup add-in to use a target folder location on both file
servers, Z and Y, at different times during my series of tests just to make
sure that its apparent misbehavior was not somehow related to a specific
file server.
5.B. I have run the experiment you suggested. The basic speed displayed as
high as 100 MiB/second. 16.2 GiB is 16588.8 MiB. At 100 MiB/second, they
should take about 166 seconds to copy (if all that had to happen was just
copy bytes). That is essentially identical to the time (165 seconds) that a
set of Windows Command Prompt COPY commands required to copy all of my PST
files. So the actual data copying proceeds as would be expected. The delay
(or elapsed time elongation) is due to the hangs/waits after the "Getting
file lock..." message, then issuing 11 "File is locked:" messages, every
time, and then immediately "Starting copying..." is exhibited. In other
words, the elongation of elapsed time to perform the backups is due to a
delay after the "Getting file lock..." messages are issued. Yet, at that
time, the PST files do not appear to be locked (according to the system
monitor utilities). The previous PST file backup utility I had installed
(the one from Microsoft itself) immediately started copying PST files after
Outlook shut down (using an ordinary file copy and displaying the same
Windows Explorer-style copy pop-up window), so it would appear to me that
the PST files are no longer locked as soon as Outlook's process actually
terminates.
Again, thanks for your quick response.
…On Sat, Dec 9, 2017 at 12:43 PM, HoffmannTom ***@***.***> wrote:
Hello,
thanks for your feedback.
1. The addin is checking whether it can get an exklusive file lock to
the pst or ost files.
If it cant get such a lock, it means another program has an open
handle to the file.
I received feedback that sometimes skype has locked the file.
You can use "process explorer" from sysinternals from microsoft to
check for open handles
(find --> find handles...)
2. it the addin doesnt wait at ost files it means that an exclusive
lock could be achieved.
What do you mean with "give up" ? Is there an error message?
Please note that backing up ost files is mostly not useful as it is
only a cache file and cant be restored on another computer.
3. The files are copied via WIN-API which is the same as copying with
explorer or command line.
If there are differences, one of the file was altered afterwards, you
compare the wrong files or you have a hardware issue.
4. What is the last message shown? Can you try to change the backup
location to a local folder?
5. The copy is made via Win-API (CopyFileEx). Maybe you can select
only this file and check the shown transfer speed (without the other pst or
ost files).
The Enterprise edition has some extra features but I dont think that the
version is related to your issues.
I hope some of the hints mentioned above helps you to figure out the issue.
Greetings,
Thomas
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Agy92UkT4lr73qpj056ZStZE1vpqJB5Hks5s-tS-gaJpZM4Q77ex>
.
|
|
Hello, to 2) You can get in touch via email at the old project location at: Greetings, |
|
Addendum: |
|
| Getting a file lock can also fail if there are not enough permissions to
this file.
That is obviously not the case since it -- all by itself -- eventually gets
the lock and proceeds and backs up the PST file.
Contacting you on the CodePlex site.
…On Sun, Dec 10, 2017 at 3:27 AM, HoffmannTom ***@***.***> wrote:
Addendum:
Getting a file lock can also fail if there are not enough permissions to
this file.
Maybe you can also try out "ProcMon" and monitor failed access rights
(result = denied).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Agy92dfKpqv0ljglo-8zx6rSKv5ugaeAks5s-6QEgaJpZM4Q77ex>
.
|
|
Attempting to contact you on the CodePlex site failed with the following
message:
Oops!
We’re sorry, but an error has occurred. The error has been logged for
review by our team.
Most likely this was an intermittent issue, please try your task again. If
you would like to contact us regarding this error, then you can use our contact
us form
<https://www.codeplex.com/site/contact?RefNumber=fa9fae00-a490-472a-94db-a846e7c13c8a&Server=CO1MSDNWBCDS04>
.
Error Reference #fa9fae00-a490-472a-94db-a846e7c13c8a
…On Sun, Dec 10, 2017 at 10:19 AM, William Blair ***@***.***> wrote:
| Getting a file lock can also fail if there are not enough permissions
to this file.
That is obviously not the case since it -- all by itself -- eventually
gets the lock and proceeds and backs up the PST file.
Contacting you on the CodePlex site.
On Sun, Dec 10, 2017 at 3:27 AM, HoffmannTom ***@***.***>
wrote:
> Addendum:
> Getting a file lock can also fail if there are not enough permissions to
> this file.
> Maybe you can also try out "ProcMon" and monitor failed access rights
> (result = denied).
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#12 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/Agy92dfKpqv0ljglo-8zx6rSKv5ugaeAks5s-6QEgaJpZM4Q77ex>
> .
>
|
|
What is the maximum size of file attachments for GitHub? I can break up the
current 4 MiB ZIP archive file into smaller ones. I just need to know how
big an attachment can be.
…On Sun, Dec 10, 2017 at 10:20 AM, William Blair ***@***.***> wrote:
Attempting to contact you on the CodePlex site failed with the following
message:
Oops!
We’re sorry, but an error has occurred. The error has been logged for
review by our team.
Most likely this was an intermittent issue, please try your task again. If
you would like to contact us regarding this error, then you can use our contact
us form
<https://www.codeplex.com/site/contact?RefNumber=fa9fae00-a490-472a-94db-a846e7c13c8a&Server=CO1MSDNWBCDS04>
.
Error Reference #fa9fae00-a490-472a-94db-a846e7c13c8a
On Sun, Dec 10, 2017 at 10:19 AM, William Blair ***@***.***>
wrote:
> | Getting a file lock can also fail if there are not enough permissions
> to this file.
>
> That is obviously not the case since it -- all by itself -- eventually
> gets the lock and proceeds and backs up the PST file.
>
> Contacting you on the CodePlex site.
>
> On Sun, Dec 10, 2017 at 3:27 AM, HoffmannTom ***@***.***>
> wrote:
>
>> Addendum:
>> Getting a file lock can also fail if there are not enough permissions to
>> this file.
>> Maybe you can also try out "ProcMon" and monitor failed access rights
>> (result = denied).
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <#12 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/Agy92dfKpqv0ljglo-8zx6rSKv5ugaeAks5s-6QEgaJpZM4Q77ex>
>> .
>>
>
>
|
|
Hello, |
|
ZIP file has been attached to an e-mail sent to the indicated address.
…On Sun, Dec 10, 2017 at 12:35 PM, HoffmannTom ***@***.***> wrote:
Hello,
I created a temporary mail address: ***@***.***
Greetings,
Thomas
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Agy92YqHXA8HOPMyaaPuOqygTKLO00GOks5s_CRZgaJpZM4Q77ex>
.
|
|
Hello, Greetings, |
|
To what e-mail address did you send it? I don't see it on this e-mail
address.
…On Wed, Dec 13, 2017 at 7:47 AM, HoffmannTom ***@***.***> wrote:
Hello,
I sent you a version with additional error information.
Hope this will lead us to the reason why an exclusive file lock is not
possible.
Greetings,
Thomas
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Agy92SdL9Eqj71SiCdxUMAUGrgt30LcTks5s_9VugaJpZM4Q77ex>
.
|
|
For the record (since other people may be reading this exchange in the
future), the developer has corrected all of the problems I encountered and
added a couple of features I suggested. Very responsive! The add-in now
works exactly as one would expect. I'm not sure when the exact version that
has been made available to me will be available here, but I assume soon.
The developer may choose to respond to this e-mail with more specific
information.
| The Enterprise edition has some extra features
I don't see the "Enterprise edition." Where is that located?
…On Wed, Dec 13, 2017 at 1:25 PM, William Blair ***@***.***> wrote:
To what e-mail address did you send it? I don't see it on this e-mail
address.
On Wed, Dec 13, 2017 at 7:47 AM, HoffmannTom ***@***.***>
wrote:
> Hello,
> I sent you a version with additional error information.
> Hope this will lead us to the reason why an exclusive file lock is not
> possible.
>
> Greetings,
> Thomas
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#12 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/Agy92SdL9Eqj71SiCdxUMAUGrgt30LcTks5s_9VugaJpZM4Q77ex>
> .
>
|
|
The issue was related to permissions. Due to moving the pst files to another location, the user had less permissions than the plugin requested. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are multiple problems when used with Office 2016 ProPlus (Enterprise). In brief: (1) Long waits after the message indicating it's trying to get the file lock. None of the PST files are locked. This happens for every PST file. (2) There is no long wait to get the file lock for the OST file, but it never gets it and gives up almost immediately. (3) It does claim, once it does lock each PST file, that it's backing it up. However, a binary compare of the original with the backup copy reveals literally tens of thousands or hundreds of thousands (or even millions+) of differences. It does not make a bit-for-bit copy of the original file. (4) It hangs on the last PST file that is selected to be backed up. That said, it allocates a file of the correct size for that file, but no data is ever copied into it. (5) The backups that it does appear to make get made about four to seven times as fast as a simple file copy. I don't see how this program can make bit-for-bit copies any faster than Windows Explorer (or another backup utility). For example, it supposedly copies one of my 9GB PST files in 17 seconds (to a file server across a gigabit LAN connection). That's impossible (as long as my switch does not run any faster than 1Gb).
The text was updated successfully, but these errors were encountered: