Hi All,

Windows 10

Cobian Reflector is throwing the following volume shadow copy errors
on a costume's Thunderbird:

ERR 2023-12-29 21:06 Error uploading the file
"GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
Mail": Cannot open file
"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
Mail". A device which does not exist was specified

Has Thunderbird 115 "what were they thinking edition" stopped
supporting Volume Shadow Copy?

Any work around? (I can kill his Thunderbird before backing up.)

Many thanks,
-T

On 29 Dec 2023 22:06:42 -0800 T wrote:
>Hi All,
>
>Windows 10
>
>Cobian Reflector is throwing the following volume shadow copy errors
>on a costume's Thunderbird:
>
>ERR 2023-12-29 21:06 Error uploading the file
>
>"GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
>Mail": Cannot open file
>
>"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
>Mail". A device which does not exist was specified
>
>
>Has Thunderbird 115 "what were they thinking edition" stopped
>supporting Volume Shadow Copy?
>
>Any work around? (I can kill his Thunderbird before backing up.)
>
>Many thanks,
>-T

Most likely Cobian. Similar errors are mentioned on their forum, e.g.
<https://forum.cobiansoft.com/viewtopic.php?t=570>

Ask there.
--
(Remove numerics from email address)

On 12/30/23 00:16, Dave Royal wrote:
> On 29 Dec 2023 22:06:42 -0800 T wrote:
>> Hi All,
>>
>> Windows 10
>>
>> Cobian Reflector is throwing the following volume shadow copy errors
>> on a costume's Thunderbird:
>>
>> ERR 2023-12-29 21:06 Error uploading the file
>>
>> "GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
>> Mail": Cannot open file
>>
>> "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
>> Mail". A device which does not exist was specified
>>
>>
>> Has Thunderbird 115 "what were they thinking edition" stopped
>> supporting Volume Shadow Copy?
>>
>> Any work around? (I can kill his Thunderbird before backing up.)
>>
>> Many thanks,
>> -T
>
> Most likely Cobian. Similar errors are mentioned on their forum, e.g.
> <https://forum.cobiansoft.com/viewtopic.php?t=570>
>
> Ask there.

Close but not quite there

"E:\Data\Thunderbird\Mail\Local Folders\Licenses\"

is not in the volume shadow.

Then again, I could always reset the volume shadow
or increase its size. But the error is "can open file",
so it does not seem to exist in the shadow. But,
not enough room in the shadow will do that too.

Also and good chkdsk may be called for too.

Thank you for writing back,
-T

On 30 Dec 2023 00:28:22 -0800 T wrote:
>
>
>Close but not quite there
>
> "E:\Data\Thunderbird\Mail\Local Folders\Licenses\"
>
>is not in the volume shadow.
>
>Then again, I could always reset the volume shadow
>or increase its size. But the error is "can open file",
>so it does not seem to exist in the shadow. But,
>not enough room in the shadow will do that too.
>
>Also and good chkdsk may be called for too.
>
>Thank you for writing back,
>-T

I didn't say that was the same error, just that Cobian had had similar
errors affecting TB directories.

This is 99% likeky to be Cobian, 5% likely to be Windows/machine, 0%
likely to be TB (to several decimal places).
--
(Remove numerics from email address)

On 30 Dec 2023 08:35:24 -0000 (UTC) Dave Royal wrote:
>
>
>I didn't say that was the same error, just that Cobian had had similar
>errors affecting TB directories.
>
>This is 99% likeky to be Cobian, 5% likely to be Windows/machine, 0%
>likely to be TB (to several decimal places).

Oops. /99/95/s ;)

--
(Remove numerics from email address)

On 12/30/23 00:36, Dave Royal wrote:
> On 30 Dec 2023 08:35:24 -0000 (UTC) Dave Royal wrote:
>>
>>
>> I didn't say that was the same error, just that Cobian had had similar
>> errors affecting TB directories.
>>
>> This is 99% likeky to be Cobian, 5% likely to be Windows/machine, 0%
>> likely to be TB (to several decimal places).
>
> Oops. /99/95/s ;)
>
>

Are you confirming that Th is properly supporting the
Shadow?

By the way, it is the only directory that is erroring out.
That may be coincidence.

I think I will create a backup jobs that only backs up Th
and see what happens. If it works, it is a Windows issue.
I wonder how full his drive is.

On 30 Dec 2023 00:51:15 -0800 T wrote:
>
>
>Are you confirming that Th is properly supporting the
>Shadow?

I don't represent the TB developers, but I'm sure they'd be surprised that
anybody thought that 'supporting' a third-party backup was a requirement
of TB.

>By the way, it is the only directory that is erroring out.
>That may be coincidence.

It's a big, constantly-changing file, in a deep directory, with uncommon
characters in the path/filename. One of those features could trip up
Cobian. (Perhaps a faulty regex ;)

>I think I will create a backup jobs that only backs up Th
>and see what happens. If it works, it is a Windows issue.
>I wonder how full his drive is.

I backup TB profiles using rsync. If I remember I stop TB first. But I
often forget.

--
(Remove numerics from email address)

On 12/30/2023 3:51 AM, T wrote:
> On 12/30/23 00:36, Dave Royal wrote:
>> On 30 Dec 2023 08:35:24 -0000 (UTC) Dave Royal wrote:
>>>
>>>
>>> I didn't say that was the same error, just that Cobian had had similar
>>> errors affecting TB directories.
>>>
>>> This is 99% likeky to be Cobian, 5% likely to be Windows/machine, 0%
>>> likely to be TB (to several decimal places).
>>
>> Oops. /99/95/s ;)
>>
>>
>
> Are you confirming that Th is properly supporting the
> Shadow?
>
> By the way, it is the only directory that is erroring out.
> That may be coincidence.
>
> I think I will create a backup jobs that only backs up Th
> and see what happens.  If it works, it is a Windows issue.
> I wonder how full his drive is.

It has a header file for VSS. But this appears to be a set of
header files for MinGW for some reason. I can't see anything
calling it. I already had this file on disk, so it wasn't
a big deal to open it up.

thunderbird-115.6.0
D:\thunderbird-115.6.0\third_party\rust\winapi\src\um\vsserror.rs

pub const VSS_E_WRITER_NOT_RESPONDING: HRESULT = 0x80042319;

D:\thunderbird-115.6.0\third_party\rust\winapi\src\um\vswriter.rs

If IMAP is checking for new mail, that might keep the file open.
Thunderbird, as far as I know, will eventually close open files
if you take hands off keyboard and idle it. If you're remoting in
and running a backup, only IMAP "any new mail" activity would violate
the premise. It isn't a VSS-related design decision. Thunderbird
does that, to reduce its footprint at runtime.

So "proper support", doesn't look like it. "Coincidental support", sorta,
but not guaranteed. If your customer had switched off the icon in the
taskbar, maybe this all would have worked by coincidence.

If you kill it, then for new mails in Draft phase, it should have made a Draft Save,
so the operator won't lose any work. What the operator will lose, is
context, like "what was I doing before Todd got here" :-)

Paul

T <T@invalid.invalid> wrote:

> Windows 10
>
> Cobian Reflector is throwing the following volume shadow copy errors
> on a costume's Thunderbird:
>
> ERR 2023-12-29 21:06 Error uploading the file
> "GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
> Mail": Cannot open file
> "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
> Mail". A device which does not exist was specified
>
> Has Thunderbird 115 "what were they thinking edition" stopped
> supporting Volume Shadow Copy?
>
> Any work around? (I can kill his Thunderbird before backing up.)

Other way around. It is not the process that opens a file handle that
needs to support VSC (Volume Shadow Copy). It's Cobian Backup trying to
read a file that may need to support VSS to get at a locked file.
Cobian should be creating a volume shadow via OS API calls to create the
snapshot file, and then read that snapshot file to backup the files
within it. Files in the snapshot are not being used by the original
processes. So, the problem seems to be Cobian cannot read the snapshot
that it had the OS create.

The only requirement of a process with an open file to cooperate with
VSC is that the process honor the request to halt writing to its file
while the VSC snapshot is being created. I don't think it needs to
close the file to unlock it, but just stop changing the file to allow
VSC to capture a static copy. However, the error you show is Cobian
attempting to get at the shadowed copy of the Tbird file, not in trying
to access the actual/real Tbird file. The snapshotting is already
completed by the time Cobian is accessing the snapshot file to get at a
particular file inside of it. While creating the snapshot, the process
should be quiescent on its access to a locked file.

Since Cobian is running as a user-mode process, did you try disabling
whatever anti-malware is running on the computer, and retry Cobian?
Shouldn't have a problem with Defender, but you may have other
anti-malware installed. Are you using controlled folder access in
Defender (not available in Home edition)? Any exploit protections in
Defender other than the defaults? Any Software Restriction Policies
(SRPs) which are policies?

I've never used Cobian nor manually ran the vssadmin commands to create
a VSC snapshot. Just looks odd for the VSC snapshot file, like it is
specifying a device path instead of a file path using a drive letter
(mount point). I just ran:

vssadmin list shadows

and, yep, \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy<xx> was listed
for the snapshot file path. It also showed the original path as
(C:)\\?\Volume{<devID>}\. GLOBALROOT is an alias to the \Global prefix
in the kernel's object namespace. \\? is the UNC prefix to "disable all
string parsing and to send the string that follows it straight to the
file system"; see:

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

The HarddiskVolumeShadowCopy<xx> is registered on the system by a
driver, and not somewhere you can navigate using File Explorer. You can
use SysInternals' WinObj tool to see the object namespaces. Under the
GLOBAL?? tree node, they all appear to be symbolic links. Right-click
on one to select Properties for more info although it may not be that
informative for you to understand.

My understanding is that a "writer" is used to create the VSC snapshot.
You can see a list of them by running:

vssadmin list writers

Can take a couple minutes before the list gets compiled and shown. For
each registered VSC writer, its last error status is listed. For
example, for Exchange data the Microsoft Exchange Server contains the
writer components, and for SQL the MS SQL Server contains the writer
components. I suspect the snapshot is not supposed to get accessed
until the VSC writer gets done creating the snapshot. I'm not a guru on
VSC, but I don't see one listed for Macrium Reflect which can use VSC to
save locked files into its backups. Could be a writer gets registered
to create the snapshot, and later de-registered. I don't know that a
VSC writer is required to read the snapshot after it is created.

Is the Volume Shadow Copy (C:\WINDOWS\system32\vssvc.exe) service set to
Manual state? Use services.msc to check. It doesn't run (state =
Running) all the time, but gets called when needed, and why its status
should be Manual. If state = Disable, VSC snapshots cannot be made.

VSC is a Windows thing (available from XP onward). Since Thunderbird is
cross-platform, perhaps they didn't consider adding a VSC writer
appropriate for that product. They likely want to avoid
platform-specific features. Rather than use one mbox file for the
message store on a per-folder basis, you might want to switch to saving
each message in its own file (maildir). I don't recall there is a way
to convert between mbox and maildir. That's something you specify when
creating a new account definition in Tbird, so you would need to change
the default message store format option in Tbired, define a new account
in Tbird (which will then use maildir) that points to the same e-mail
server as the old account that is using mbox. Maildir was/is considered
a beta feature, but that was many years ago, so I don't know if its beta
status is gone. A writer is something a program has that does its own
VSC snapshotting, so I wouldn't think Tbird would have one nor need one.
It would be Cobian that creates the snapshots that might need a writer
assuming some common one already registered isn't reused.

https://support.mozilla.org/en-US/kb/maildir-thunderbird
https://wiki.mozilla.org/Thunderbird/Maildir

The article has a link to a search at bugzilla.mozilla.org on maildir,
so you might want to read them before switching to it. With mbox, it
could be locked anytime there is any changes made to a folder in Tbird.
With maildir, a particular file would only be locked while Tbird was
making changes to it, like when receiving a new message to store in a
new maildir file.

Is Cobian saving backups to local storage, or remotely over a network
connection? I would test by having Cobian save to local storage, and
use SyncBack, FreeFileSync, or a post-backup job FTP to get copies of
the backup files to networked storage.

On 12/30/23 03:03, Paul wrote:
> On 12/30/2023 3:51 AM, T wrote:
>> On 12/30/23 00:36, Dave Royal wrote:
>>> On 30 Dec 2023 08:35:24 -0000 (UTC) Dave Royal wrote:
>>>>
>>>>
>>>> I didn't say that was the same error, just that Cobian had had similar
>>>> errors affecting TB directories.
>>>>
>>>> This is 99% likeky to be Cobian, 5% likely to be Windows/machine, 0%
>>>> likely to be TB (to several decimal places).
>>>
>>> Oops. /99/95/s ;)
>>>
>>>
>>
>> Are you confirming that Th is properly supporting the
>> Shadow?
>>
>> By the way, it is the only directory that is erroring out.
>> That may be coincidence.
>>
>> I think I will create a backup jobs that only backs up Th
>> and see what happens.  If it works, it is a Windows issue.
>> I wonder how full his drive is.
>
> It has a header file for VSS. But this appears to be a set of
> header files for MinGW for some reason. I can't see anything
> calling it. I already had this file on disk, so it wasn't
> a big deal to open it up.
>
> thunderbird-115.6.0
> D:\thunderbird-115.6.0\third_party\rust\winapi\src\um\vsserror.rs
>
> pub const VSS_E_WRITER_NOT_RESPONDING: HRESULT = 0x80042319;
>
> D:\thunderbird-115.6.0\third_party\rust\winapi\src\um\vswriter.rs
>
> If IMAP is checking for new mail, that might keep the file open.
> Thunderbird, as far as I know, will eventually close open files
> if you take hands off keyboard and idle it. If you're remoting in
> and running a backup, only IMAP "any new mail" activity would violate
> the premise. It isn't a VSS-related design decision. Thunderbird
> does that, to reduce its footprint at runtime.
>
> So "proper support", doesn't look like it. "Coincidental support", sorta,
> but not guaranteed. If your customer had switched off the icon in the
> taskbar, maybe this all would have worked by coincidence.
>
> If you kill it, then for new mails in Draft phase, it should have made a Draft Save,
> so the operator won't lose any work. What the operator will lose, is
> context, like "what was I doing before Todd got here" :-)
>
> Paul

Hi Paul,

As usual, a fantastic piece of technical writing. Much
appreciated!

The backup goes off in the middle of the night. And I do
have the ability to kill running processes. And yes, I know
of people that start things and walk away for hours or days
then get angry that something happens that causes them to
lose their work and they and too FREAKIN' LAZY to press
"Save" before walking away. (And it is ALL my fault.)

Come to think of it, there are about seven other
Cobian backups at their facility, all of which use
Thunderbird. They do not have this problem. I usually
only see a problem with parent.lock, but I typically
will exclude it from backup to get rid of the error.
There is no reason for 40+ VSS errors from Thunderbird
on only one machine.

So armed with your information, I will look to a Windows
issue. And I have a YUGE write up in my keepers file
on troubleshooting and tweaking the shadow.

I wonder how many days have passed since he rebooted.

-T

On 12/30/23 08:30, VanguardLH wrote:
> T <T@invalid.invalid> wrote:
>
>> Windows 10
>>
>> Cobian Reflector is throwing the following volume shadow copy errors
>> on a costume's Thunderbird:
>>
>> ERR 2023-12-29 21:06 Error uploading the file
>> "GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
>> Mail": Cannot open file
>> "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent
>> Mail". A device which does not exist was specified
>>
>> Has Thunderbird 115 "what were they thinking edition" stopped
>> supporting Volume Shadow Copy?
>>
>> Any work around? (I can kill his Thunderbird before backing up.)
>
> Other way around. It is not the process that opens a file handle that
> needs to support VSC (Volume Shadow Copy). It's Cobian Backup trying to
> read a file that may need to support VSS to get at a locked file.
> Cobian should be creating a volume shadow via OS API calls to create the
> snapshot file, and then read that snapshot file to backup the files
> within it. Files in the snapshot are not being used by the original
> processes. So, the problem seems to be Cobian cannot read the snapshot
> that it had the OS create.

This is my understaning of what is happening with Cobian

> The only requirement of a process with an open file to cooperate with
> VSC is that the process honor the request to halt writing to its file
> while the VSC snapshot is being created. I don't think it needs to
> close the file to unlock it, but just stop changing the file to allow
> VSC to capture a static copy. However, the error you show is Cobian
> attempting to get at the shadowed copy of the Tbird file, not in trying
> to access the actual/real Tbird file. The snapshotting is already
> completed by the time Cobian is accessing the snapshot file to get at a
> particular file inside of it. While creating the snapshot, the process
> should be quiescent on its access to a locked file.

There is is that Cobian can't find the file in the shadow. So you
have a point.

> Since Cobian is running as a user-mode process,

It is running as "SYSTEM". You can run it in user mode but
too may thing go wrong ...

> did you try disabling
> whatever anti-malware is running on the computer, and retry Cobian?
> Shouldn't have a problem with Defender, but you may have other
> anti-malware installed. Are you using controlled folder access in
> Defender (not available in Home edition)? Any exploit protections in
> Defender other than the defaults? Any Software Restriction Policies
> (SRPs) which are policies?

Maybe. But I have probably 50 of them running at various customer
sites which all kind of various AV's and do not have a problem.

That does not mean that this site is immune. I can't tell you how nay
"one off" issues I have had to solve with W10/11 that happen nowhere
else.

So disabling is something I will try.

> I've never used Cobian nor manually ran the vssadmin commands to create
> a VSC snapshot. Just looks odd for the VSC snapshot file, like it is
> specifying a device path instead of a file path using a drive letter
> (mount point). I just ran:
>
> vssadmin list shadows

My memory is that it does list Cobian whilst Cobian is running.

> and, yep, \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy<xx> was listed
> for the snapshot file path. It also showed the original path as
> (C:)\\?\Volume{<devID>}\. GLOBALROOT is an alias to the \Global prefix
> in the kernel's object namespace. \\? is the UNC prefix to "disable all
> string parsing and to send the string that follows it straight to the
> file system"; see:
>
> https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

Asewome link!
>
> The HarddiskVolumeShadowCopy<xx> is registered on the system by a
> driver, and not somewhere you can navigate using File Explorer. You can
> use SysInternals' WinObj tool to see the object namespaces. Under the
> GLOBAL?? tree node, they all appear to be symbolic links. Right-click
> on one to select Properties for more info although it may not be that
> informative for you to understand.
>
> My understanding is that a "writer" is used to create the VSC snapshot.
> You can see a list of them by running:
>
> vssadmin list writers
>
> Can take a couple minutes before the list gets compiled and shown. For
> each registered VSC writer, its last error status is listed. For
> example, for Exchange data the Microsoft Exchange Server contains the
> writer components, and for SQL the MS SQL Server contains the writer
> components. I suspect the snapshot is not supposed to get accessed
> until the VSC writer gets done creating the snapshot. I'm not a guru on
> VSC, but I don't see one listed for Macrium Reflect which can use VSC to
> save locked files into its backups. Could be a writer gets registered
> to create the snapshot, and later de-registered. I don't know that a
> VSC writer is required to read the snapshot after it is created.

I miss Linux being able to read any file in read only mode. Any writer
is just held off until the reader finishes.

> Is the Volume Shadow Copy (C:\WINDOWS\system32\vssvc.exe) service set to
> Manual state? Use services.msc to check. It doesn't run (state =
> Running) all the time, but gets called when needed, and why its status
> should be Manual. If state = Disable, VSC snapshots cannot be made.

Here is the thing, no other files outside of Thunderbird is giving the
issue. If VSS was going wrong, it would not cough on 40+ files
in Thunderbird and nowhere else. Then again that "one off" thing.

>
> VSC is a Windows thing (available from XP onward). Since Thunderbird is
> cross-platform, perhaps they didn't consider adding a VSC writer
> appropriate for that product. They likely want to avoid
> platform-specific features. Rather than use one mbox file for the
> message store on a per-folder basis, you might want to switch to saving
> each message in its own file (maildir). I don't recall there is a way
> to convert between mbox and maildir. That's something you specify when
> creating a new account definition in Tbird, so you would need to change
> the default message store format option in Tbired, define a new account
> in Tbird (which will then use maildir) that points to the same e-mail
> server as the old account that is using mbox. Maildir was/is considered
> a beta feature, but that was many years ago, so I don't know if its beta
> status is gone. A writer is something a program has that does its own
> VSC snapshotting, so I wouldn't think Tbird would have one nor need one.
> It would be Cobian that creates the snapshots that might need a writer
> assuming some common one already registered isn't reused.
>
> https://support.mozilla.org/en-US/kb/maildir-thunderbird
> https://wiki.mozilla.org/Thunderbird/Maildir
>
> The article has a link to a search at bugzilla.mozilla.org on maildir,
> so you might want to read them before switching to it. With mbox, it
> could be locked anytime there is any changes made to a folder in Tbird.
> With maildir, a particular file would only be locked while Tbird was
> making changes to it, like when receiving a new message to store in a
> new maildir file.
>
> Is Cobian saving backups to local storage, or remotely over a network
> connection? I would test by having Cobian save to local storage, and
> use SyncBack, FreeFileSync, or a post-backup job FTP to get copies of
> the backup files to networked storage.

He has two backup jobs. One saves to a USB external drive. The
other saves to a local vsftp server. FTP is my favorite method
as ransom ware has yet to figure it out. I had to save
someone at that company already from ransom ware. Got
her external backup drive but good, hidden volumes
and all. Couldn't find her ftp backup.

I am starting to wonder just exactly how many days his computer
has been running without a reboot. Windows does start going weird
after about three days of continuous running. And he does leave
Thunderbird running 24/7. (I also have Fast Startup disabled
and I doubt he knows how to run it back on. And it has been
a few years now since I have seen an m$ update re-enable it.)

I am waiting for permission to fix the user's computer from my
handler at the company. I do have unattended support, but
I never use it unless they authorize me in advance.

Wonderful technical writing! Thank you!
-T

T <T@invalid.invalid> wrote:

> He has two backup jobs. One saves to a USB external drive. The
> other saves to a local vsftp server. FTP is my favorite method
> as ransom ware has yet to figure it out. I had to save
> someone at that company already from ransom ware. Got
> her external backup drive but good, hidden volumes
> and all. Couldn't find her ftp backup.
>
> I am starting to wonder just exactly how many days his computer
> has been running without a reboot. Windows does start going weird
> after about three days of continuous running. And he does leave
> Thunderbird running 24/7. (I also have Fast Startup disabled
> and I doubt he knows how to run it back on. And it has been
> a few years now since I have seen an m$ update re-enable it.)
>
> I am waiting for permission to fix the user's computer from my
> handler at the company. I do have unattended support, but
> I never use it unless they authorize me in advance.
>
> Wonderful technical writing! Thank you!
> -T

I would still try switching to maildir. When Tbird is doing anything
with a folder whether it be Inbox for getting new messages or exercising
rules to move messages to different folders, the entire mbox file will
be in-use. Whereas when using maildir, just the message file is in-use
(well, there are other management data kept in other files, but you're
not having problems backing up those).

The error you mention was about the shadow copy of the Sent folder. Is
Cobian running off-hours, so the user(s) is unlikely to be using it to
*send* out messages during the backup? Sending would involve both the
Outbox and Sent folders. Or was this just an example error, and other
Tbird folders have been specified in other backup errors?

Other than the user composing a new message and then sending it, is the
user employing the Sent Later feature in Tbird or via add-on? If Cobian
is running off-hours, the expectation is the user isn't using Tbird.
Tbird might be updating the Inbox and other folders via rules during the
scheduled mail sessions or via IMAP PUSH, but the Sent folder should be
or expected to be quiescent during off-hours. Despite Tbird left
running 24x7, you said the computer is up 24x7. Seems the Cobian
backups could be scheduled to run off-hours.

The error "A device which does not exist was specified" could be about
the snapshot file, or the device where the snapshot file was stored. Is
Cobian saving VSC snapshots to an internal drive, or to an attached or
networked drive? I don't where is HarddiskVolumeShadowCopy157912. That
would be something I'd check using the WinObj tool to look at its
properties. You'd think it was an internal hard disk by its name.

Are there any batch scripts, scheduled events, or anything that might be
unmounting volumes at the time of the Cobian backup? I ask, because at
one time I used to run a pre-backup job to:

- Enable device (hard disk on SATA port).
- Mount the backup partition as a drive letter.

And later run a post-backup job that:

- Unmounted the drive.
- Disabled the device.

I use devcon.exe, an old tool, to disable the device from the command
line. There might be other methods, but getting devcon.exe worked to do
what the GUI tool (devmgmt.msc) could do. The purpose was to save
backups to a partition (seen as a drive letter) that was not available
other than when the backup job was running. This hid the backup
location, so most malware couldn't find the backup files. It is still
possible malware could find them since malware can do the same as I or
any commands I specify in a batch script. It was simple to raise the
bar to find the backup files; however, there was a window of opportunity
during the backup when the backup location could easily be found.
However, later Macrium came out with their Image Guardian which works
like a rootkit to limit access to its backup files to only the Reflect
program, so I didn't need my pre- and post-backup job scripts.

There could be other processes, scheduled tasks, services, or whatnot
that make a device hidden (remove drive letter, unmount the device).
However, I would think if that happened that Cobian would complain about
all files in the snapshot being unavailable.

You say the computer runs 24x7. Have you ensure that nothing will cause
a reboot, like Windows Update? Or a scheduled event in Task Scheduler?
I've seen users that leave the computer up 24x7, but schedule a reboot
via "shutdown.exe /r". The reasons vary, but often the user considers
Windows too unstable to leave up running too long. Being up 24x7 does
not specifically exclude reboots. My understanding is VSC snapshot are
deleted on reboot (volsnap eventid 32 in Event Viewer). Another problem
is timeout on the device where the snapshot is stored (eventid 25).

I've seen problems regarding high file count or large file size when
using USB for mass storage. Is Cobian saving its backup files to an
internal drive, and then they later get copied or moved to the USB
drive? I would expect the setup to have Cobian save to an internal
drive, and then copy those to USB and send to FTP.

On 12/30/23 16:50, VanguardLH wrote:
> T <T@invalid.invalid> wrote:
>
>> He has two backup jobs. One saves to a USB external drive. The
>> other saves to a local vsftp server. FTP is my favorite method
>> as ransom ware has yet to figure it out. I had to save
>> someone at that company already from ransom ware. Got
>> her external backup drive but good, hidden volumes
>> and all. Couldn't find her ftp backup.
>>
>> I am starting to wonder just exactly how many days his computer
>> has been running without a reboot. Windows does start going weird
>> after about three days of continuous running. And he does leave
>> Thunderbird running 24/7. (I also have Fast Startup disabled
>> and I doubt he knows how to run it back on. And it has been
>> a few years now since I have seen an m$ update re-enable it.)
>>
>> I am waiting for permission to fix the user's computer from my
>> handler at the company. I do have unattended support, but
>> I never use it unless they authorize me in advance.
>>
>> Wonderful technical writing! Thank you!
>> -T
>
> I would still try switching to maildir. When Tbird is doing anything
> with a folder whether it be Inbox for getting new messages or exercising
> rules to move messages to different folders, the entire mbox file will
> be in-use. Whereas when using maildir, just the message file is in-use
> (well, there are other management data kept in other files, but you're
> not having problems backing up those).
>
> The error you mention was about the shadow copy of the Sent folder. Is
> Cobian running off-hours, so the user(s) is unlikely to be using it to
> *send* out messages during the backup? Sending would involve both the
> Outbox and Sent folders. Or was this just an example error, and other
> Tbird folders have been specified in other backup errors?
>
> Other than the user composing a new message and then sending it, is the
> user employing the Sent Later feature in Tbird or via add-on? If Cobian
> is running off-hours, the expectation is the user isn't using Tbird.
> Tbird might be updating the Inbox and other folders via rules during the
> scheduled mail sessions or via IMAP PUSH, but the Sent folder should be
> or expected to be quiescent during off-hours. Despite Tbird left
> running 24x7, you said the computer is up 24x7. Seems the Cobian
> backups could be scheduled to run off-hours.
>
> The error "A device which does not exist was specified" could be about
> the snapshot file, or the device where the snapshot file was stored. Is
> Cobian saving VSC snapshots to an internal drive, or to an attached or
> networked drive? I don't where is HarddiskVolumeShadowCopy157912. That
> would be something I'd check using the WinObj tool to look at its
> properties. You'd think it was an internal hard disk by its name.
>
> Are there any batch scripts, scheduled events, or anything that might be
> unmounting volumes at the time of the Cobian backup? I ask, because at
> one time I used to run a pre-backup job to:
>
> - Enable device (hard disk on SATA port).
> - Mount the backup partition as a drive letter.
>
> And later run a post-backup job that:
>
> - Unmounted the drive.
> - Disabled the device.
>
> I use devcon.exe, an old tool, to disable the device from the command
> line. There might be other methods, but getting devcon.exe worked to do
> what the GUI tool (devmgmt.msc) could do. The purpose was to save
> backups to a partition (seen as a drive letter) that was not available
> other than when the backup job was running. This hid the backup
> location, so most malware couldn't find the backup files. It is still
> possible malware could find them since malware can do the same as I or
> any commands I specify in a batch script. It was simple to raise the
> bar to find the backup files; however, there was a window of opportunity
> during the backup when the backup location could easily be found.
> However, later Macrium came out with their Image Guardian which works
> like a rootkit to limit access to its backup files to only the Reflect
> program, so I didn't need my pre- and post-backup job scripts.
>
> There could be other processes, scheduled tasks, services, or whatnot
> that make a device hidden (remove drive letter, unmount the device).
> However, I would think if that happened that Cobian would complain about
> all files in the snapshot being unavailable.
>
> You say the computer runs 24x7. Have you ensure that nothing will cause
> a reboot, like Windows Update? Or a scheduled event in Task Scheduler?
> I've seen users that leave the computer up 24x7, but schedule a reboot
> via "shutdown.exe /r". The reasons vary, but often the user considers
> Windows too unstable to leave up running too long. Being up 24x7 does
> not specifically exclude reboots. My understanding is VSC snapshot are
> deleted on reboot (volsnap eventid 32 in Event Viewer). Another problem
> is timeout on the device where the snapshot is stored (eventid 25).
>
> I've seen problems regarding high file count or large file size when
> using USB for mass storage. Is Cobian saving its backup files to an
> internal drive, and then they later get copied or moved to the USB
> drive? I would expect the setup to have Cobian save to an internal
> drive, and then copy those to USB and send to FTP.

Hi VanguardLH,

Wow, you put a lot of work into that letter! Thank you!

Any scripts are my doing.

I may have set his computer to reboot at 03:00 in the morning.

But I set the reboot and the backup apart by far more than
enough time that they do not conflict.

Also, a reboot would have clobbered Cobian as well.

I like to use
shutdown /r /f /t 20
for the nightly reboots

I think at this point, I should wait to get permission
to use my unattended support to log in and find out
what is really happening.

I am fairly assured that Thunderbird 115+ "what were
they thinking edition" is not the issue. Paul
did check the file headers for VSS support
for me.

The only file in Thunderbird I have had a VSS issues
with is parent.lock, but I exclude it.

-T

On 12/29/23 22:06, T wrote:
> Hi All,
>
> Windows 10
>
> Cobian Reflector is throwing the following volume shadow copy errors
> on a costume's Thunderbird:
>
> ERR 2023-12-29 21:06 Error uploading the file
> "GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent Mail": Cannot open file "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy157912\Users\Todd\AppData\Roaming\Thunderbird\Profiles\2hdyr429.default\ImapMail\imap.secureserver.net\[Gmail]-1.sbd\Sent Mail". A device which does not exist was specified
>
>
> Has Thunderbird 115 "what were they thinking edition" stopped
> supporting Volume Shadow Copy?
>
> Any work around?  (I can kill his Thunderbird before backing up.)
>
> Many thanks,
> -T

Feedback.

A reboot fixed it. He leaves his computer running 24/7.

I am setting him up to reboot every Monday morning at
03:00

Thank you all for the tips!

-T

On 5 Jan 2024 17:40:35 -0800 T wrote:

>A reboot fixed it.

Remember Dogbert's tech support?
--
(Remove numerics from email address)

On 1/6/24 00:26, Dave Royal wrote:
> On 5 Jan 2024 17:40:35 -0800 T wrote:
>
>> A reboot fixed it.
>
> Remember Dogbert's tech support?

Oh you bet!

https://www.pinterest.com/pin/dogberts-tech-support--482377810076086001/

:-D

Dave Royal wrote:

>>A reboot fixed it.
>
>Remember Dogbert's tech support?

Have you tried to switch it off and on again?

-jw-

--

And now for something completely different...

On 1/6/24 02:09, Joerg Walther wrote:
> Dave Royal wrote:
>
>>> A reboot fixed it.
>>
>> Remember Dogbert's tech support?
>
> Have you tried to switch it off and on again?
>
> -jw-
>

https://www.youtube.com/watch?v=p85xwZ_OLX0

T wrote:

>> Have you tried to switch it off and on again?

>https://www.youtube.com/watch?v=p85xwZ_OLX0

Exactly.

-jw-

--

And now for something completely different...

On 1/7/24 00:58, Joerg Walther wrote:
> T wrote:
>
>>> Have you tried to switch it off and on again?
>
>> https://www.youtube.com/watch?v=p85xwZ_OLX0
>
> Exactly.
>
> -jw-
>

I have had a few on another group get pissy with me
before for rebooting instead of fixing the issue.

Windows universal cure all:
<win><R> shutdown /r /f /t 00

Am 07.01.24 um 10:22 schrieb T:
> On 1/7/24 00:58, Joerg Walther wrote:
>> T wrote:
>>
>>>> Have you tried to switch it off and on again?
>>
>>> https://www.youtube.com/watch?v=p85xwZ_OLX0
>>
>> Exactly.
>>
>> -jw-
>>
>
>
> I have had a few on another group get pissy with me
> before for rebooting instead of fixing the issue.
>
> Windows universal cure all:
> <win><R> shutdown /r /f /t 00

Always when this crappy OS is involved this is the starting point of any
rectification process.

--
"Gutta cavat lapidem." (Ovid)

On 1/7/24 03:02, Jörg Lorenz wrote:
> Am 07.01.24 um 10:22 schrieb T:
>> On 1/7/24 00:58, Joerg Walther wrote:
>>> T wrote:
>>>
>>>>> Have you tried to switch it off and on again?
>>>
>>>> https://www.youtube.com/watch?v=p85xwZ_OLX0
>>>
>>> Exactly.
>>>
>>> -jw-
>>>
>>
>>
>> I have had a few on another group get pissy with me
>> before for rebooting instead of fixing the issue.
>>
>> Windows universal cure all:
>>      <win><R> shutdown /r /f /t 00
>
> Always when this crappy OS is involved this is the starting point of any
> rectification process.
>

What you stated is simple common sense. Why anyone would
think otherwise is beyond me.

On 1/7/24 00:58, Joerg Walther wrote:
> T wrote:
>
>>> Have you tried to switch it off and on again?
>
>> https://www.youtube.com/watch?v=p85xwZ_OLX0
>
> Exactly.
>
> -jw-
>

You know something, the more I think about it, the
more I think the I.T. Squad is trying to make fun
of us. But so far, it escapes me as to how.