Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

Bug?: Wildcards both in BE2010 GUI as in BEMCMD Command Line Applet not working properly (Restore/ Searching the catalogs)

Created: 28 Aug 2013 • Updated: 14 Oct 2013 | 24 comments
This issue has been solved. See solution.

Dear Backup Exec 2010 users and supporters,

I encounter huge problems searching the catalogs with wildcards. I read the Admin and BEMCMD manual, which doesn't refer to wildcard supported AT ALL. I tested this with BE2010 R3 SP0 to SP2, respective BEMCMD  13.0.5204

I read the forum, but still there is much confusion. Technical support hotline is a bad joke about this topic.

E.g. here, a Symantec advisor wrote, that wildcards aren't supported what is also wrong, which I will show below.

In the GUI, you will get strange results when searching for *.* (the .raw file is not found by this as shown in the image below), but (probably) good results when searching for ?*.*



With the command line applet "BEMCMD" option -o38 (search the catalogs) it is even worse.

-fn:*.raw won't work

-fn:?*.raw will work!

-fn:????????????.raw will work! (but You will have to know the exact length of the file names)

-fn:?*.* won't work

-fn:?*.??? won't work

-fn:?*.r?? will work! Crazy! for *.* you will have to iterate through ?*.a??, ?*.b??, ?*.c?? ... at the moment :-)

Am I doing something wrong here? Is there a fix?

Operating Systems:

Comments 24 CommentsJump to latest comment

VJware's picture

Wildcard are supported. KB -

And the forum post mentioned above does not have a comment by symantec support, but rather than an external customer.

I don't think *.* will work as simply leaving this field blank will return all items. (Similar to searching via *.*)

dl2rcf's picture

I don't think *.* will work as simply leaving this field blank will return all items. (Similar to searching via *.*)

Neither in BE2010 GUI catalog search nor with BEMCMD does a blank field return any item.

Also these variants won't work with BEMCMD:

1. leaving the -fn: away

2. ... -fn:

3. ... -fn:*

...primary I thought of a text parsing bug regarding "*.*" (perhaps only in the German version as there are . and , problems sometimes using German software on a US-localized OS and the other way round). But then the wildcard * alone wont work neither with BEMCMD.... 

VJware's picture

I am not sure about BEMCMD yet & let me check a bit. (The above comment was for searching via the UI )

And are the Catalogs folder residing on the default path or moved to an alternate location. If to an alternate location, pls do check there is no mismatch in the Catalogs location from the UI and the registry. Secondly, hope these searches are not for GRT or Application backups as catalog search works only for file system backups.

dl2rcf's picture

Thanks for supporting.

In the first thread, I mentioned BEMCMD at the bottom with examples that work/won't work. Take Your time to check it, but please keep responding, since I have no other way to find support on this...

The catalogs have never moved from the initial default location and are not truncated.

Excuse me, but what do You mean by GRT?

The catalog searches I need for restoring single files that got deleted from the main server from time to time if someone after time demands that file again (after years!).

In our surrounding (huge) files are stored by the users on the 20TB server. Normally they will change never but if so, only a few days after storing them the first time. All files will be back upped incrementally by BE2010. After ~6 months the files get deleted semi-automatically by the server (always the oldest ones).

But regularly files will be requested years(!) after the backup job backed them up and I (Admin) will restore them manually for this user by searching the catalog of that 1000TB tape robot...this is what I am testing at the moment.

Am I doing something wrong here? Any suggestion would help me...The catalog is not corrupt, since the files will be displayed correctly if entered the plain name.

But many times, users don't remember the exact name(s) after some years :-) or he/she wants many files at once restored. So wildcard searches would definitely be needed!

Thanks in advance,


VJware's picture

Upon keeping all fields blank in the UI or running just bemcmd -o38 returns results on my test machine.

Infact, running the following worked in my case.

bemcmd -o38 -fn:           (Returned all results)

bemcmd -o38 -fn: *.*      (Returned all results)

bemcmd -o38 -fn: *.exe   (Returned all .exe files)

Noticed one difference that i have a whitespace in the switch used i.e. whitespace between fn: and *

dl2rcf's picture

Hello VJware,

what version of BEMCMD/ BE2010 are You running?

I have BEMCMD 13.0.5204 and BE2010 R3 SP2 (but tested with other SPs as well)

These are my crazy results (please note that introducing a whitespace in between worsten my results :-) ):

C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn:????????????????.raw -s -co:

Number of matched items found: 9


C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn: 169_11_17_44.875.raw -s -co:

Number of matched items found: 0


C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn:169_11_17_44.875.raw -s -co:

Number of matched items found: 1


C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn: *.raw -s -co:

Number of matched items found: 0


C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn: *.* -s -co: > test4.txt

Number of matched items found: 0


C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn:?*.raw -s -co:

Number of matched items found: 9


C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn: ?*.raw -s -co:

Number of matched items found: 0

VJware's picture

I am using 2010 R3 with SP3.

Double-checked and my apologies.

Results are fine without a whitespace (-fn:*.exe)

All results are shown when whitespace is used (-fn: *.exe)

From your above examples, the command is indeed running fine without a whitespace.

dl2rcf's picture

Do You know, if this is an issue targeted by SP3. I read all the details of SP3, but didn't find the issue. Due to the hint, that You cannot uninstall SP3 and it is very recent, I did not apply it yet...

Could You tell me the version that BEMCMD announces itself when called?

dl2rcf's picture

Thats unfair!

I upgraded BE2010 R3 to SP3 ... and still have 13.0.5204.1225

Edit: hmm, my version number is higher than yours, but still I encounter the same problem as described above

where to obtain your version, if not with the latest service pack, sir?


VJware's picture

I possibly have a non-public version of the BEMCMD.

However, per your examples earlier such as -

C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn:????????????????.raw -s -co:

Number of matched items found: 9

C:\Program Files\Symantec\BackupExec2010R3>bemcmd -o38 -sn:FDAS-SRV1 -vn:O: -pa:
1125\019 -fn:?*.raw -s -co:

Number of matched items found: 9

These look like working as expected with wildcards. I may be missing something, but do you have any other examples of an actual file which you were trying to search from catalogs (Provided the storage has been cataloged)

dl2rcf's picture

I may be missing something, but do you have any other examples of an actual file which you were trying to search from catalogs

You want S'MORE examples?! OK let's see


As I said, the behaviour is repetitive/ predictable. It's the same with all file types. ALL file sizes will be wrong (~400 Bytes instead of 100kB - 50GB), too, ( if you don't use "-co:" as done here only for the purpose of shortening the output for clarity here). Results of counting "-co:" and full output is always the same...

These look like working as expected with wildcards.

Yes, but *.* won't work. I sent You the examples just to show You how weird the behaviour is...having to emulate *.* with ?*.a??, then ?*.b??, then ?*.c??, ?*.d?? and so on. And thus you cover only "all" files with a "good ol" 3-character file name extension. Files like .config won't be seen so. It is a bug!

Please let me have Your version for testing purposes! I won't pass it away and perhaps we can track down a bug that way, so in the next hotfix this could be solved. If the problem stays the same with Your version IMHO it could be the German localization, since the catalog itself is working.

I desperately need the search catalog functionality from command line...

Let's track down that bug!

dl2rcf's picture

...any news how to get Your version 13.0.5204.1088?

Could You send me Your version for me to test it. How come You and me having the same version and service packs of BE, but differ in BEMCMD versions?

Is this a language/ localization issue?

Could we testwise use the english version of BE2010 with our german license?

Thanks in advance... Ruben

pkh's picture

To be fair to Ken Putnam, you must read the context in which he made the comment that wildcards are not supported by BEMCMD.  He was referring to using wildcards in the jobname switch of the applet.  He is not referring to a wildcard search of the catalog.

pkh's picture

Even if there is a bug in BEMCMD, it will not be fixed.  BEMCMD is replaced by BEMCLI in BE 2012, so I would not waste much time on BEMCMD.

dl2rcf's picture

Excuse me sir,

but that should NEVER be an acceptable attitude towards a pretty recent product. I worked for technical support in my last company and we fixed or at least gave the customer a workaround for products even +10 years old.

A company as Symantec relying on "security" products e.g. Backup, Antivirus should be willing to do everything economically viable to track down bugs...and fixing a standalone command line tool should not be such a great effort.

Another thing is: probably no changes of code is needed: Wildcards work as supposed with VJware's version.

The bug is tracked to only 2 things:

- Standard BEMCMD has this bug and his special version don't --> providing his BEMCMD version to the customer

- (worse, but ok) German localization is the problem --> so we get/ if necessary buy the english one

I hope You understand my point of view. Thanks for responding and keeping the thread alive till a solution is found. The solution is near :-)

Best regards,


VJware's picture

Hello Ruben,

I don't think I have a 'special' version of BEMCMD...I used a slip-streamed installer (BE 2010 R3 + SP3) and I believe that's why the version number is different in my case.

I would recommend you to log a support case so that support can review your issue formally. Thanks.

dl2rcf's picture

Hi VJware,

I opened a support case #04997405 and will report here as soon as I have new informations.

Meanwhile I still would be pleased to test your version. Just send it to [removed by Ruben]. Otherwise, if you give me any way to send you a file, I can send You my BEMCMD version so to check on your machine...

Best  regards,


Edit [12.09.2013]: This is not a BEMCMD issue (confd), but a general catalog search engine issue. So no need for the "other" BEMCMD version anymore...

dl2rcf's picture

Could this perhaps be some kind of time out or buffer overflow, that is not announced to the user?


Both searches (behaviour in GUI as with BEMCMD -o38) take ALWAYS the same amount of time, either when searching a small drive with 1000 files as with a drive that has 2,000,000+ files.

IMHO, a wildcard search on the "big drive" one should take MUCH longer and by that, give back more files as a
result (or at least a time out or overflow warning...).

...Tech Support is still working on this...

dl2rcf's picture

I got new insights on this issue that are boat rocking! I am only wondering why this issue didn't bother anybody yet?!?! The issue is yet occuring when restoring from a backup with 10000+ files/folders ONLY within one drive.

I hereby promise to post them, after tech support had a chance to look over them...Ruben

dl2rcf's picture

As promised, I hereby reveal the confirmed source of the error: It is the search engine of the catalog search (both GUI and BEMCMD).

In short the search engine has the following (confd) problems:

- Limited buffer of search engine buffer entries. Default = 10000 entries. Changeable by (only for GUI, BEMCMD will ignore your settings): HKEY_CURRENT_USER\Software\Symantec\Backup Exec For Windows\StoreX\13.0\Media Search Max Count

This alone is not a problem. The real problem is the following:


*1) Within the search mask of the GUI catalog search (and of course the command line options of BEMCMD accordingly), there are text fields to which I refer hereby as "filters". While the "file name", "Ressource" and "include sub directories" filters work as they should (files not targetted by the filters will be completely ignored during search) the filters "Path" and "Find directory" will be applied AFTER the search has finished (who ever did the programming here...). Thus leading to the 10000-item buffer (mentioned above) "soaks itself full" and leads to early abort of the search.

*1b) by the way, there is a hidden wildcard with the "Path" field. So, if You search for "FolderX", then "FolderX1", "FolderX2", "FolderXARJFKL"... you name it, will be searched as well, thus adding to the buffer soaking problem

*2) The bigger problem is that the user will not securely be informed about search abort due to buffer full with the nice warning popup displayed in *2) (in BEMCMD You will be never warned at all, the "result" value stays always the same). So You can never be sure whether the search result is actually displaying the real content of the catalog or if there was a "hidden search abort". This is because, if "the buffer soaked itselft full" of "Media Search Max Count" items (10000 per default), You will only be notified when *1) not happend that is if no items are to be filtered out AFTER the search has finished.

I ran extended test here, with a fresh catalog and simple flat full backup with 10000 to 20000 files and was even able to predict results...

I am fighting with technical support, even with the "advanced" one for almost 2 months now asking lately to just:

1. Applying the filter "Path" "[x] find directories" when search is parsing the catalog, NOT after
2. eliminating the hidden wildcard "*" from "Path" filter (so that only when explicitly attaching the wildcard "*" to the path, such as Path10*, will Catalog Search search within Path100, Path101, Path102...)
3. Throwing the Warning "maximum number of search results (...) has been reached" when buffer overflow during seach occurred, not when (GUI-Result.Count entries == HKEY_CURRENT_USER\Software\Symantec\Backup Exec For Windows\StoreX\13.0\Media Search Max Count)

The only response I get is:

- "That [catalog search] is not [core] functionality of our product" ??!!! So how do You restore specific files then ??!! IMHO RESTORE is an important functionality of a BACKUP product.

- "Symantec recommends customers to switch to another software, namely BE2012"... well perhaps we will switch, but defenitly not to another Symantec product! I am going to attend a BE2010 course, where I will demonstrate the error...

You just lost a customer.

Best regards, Ruben

pkh's picture

Whichever backup software that you decide to switch to, do make sure that you subject it to a stress-test like the above.  Otherwise, you would be disappointed again.

dl2rcf's picture

...will do so. Thanks for caring!

However, I am disapointed that Symantec refused to fix at least *2) that the user regardless of "buffer soaking" can be sure whether the search is complete or not.

This should be a 1-2 line code change!

Then, the user could:

- increase the "Max Value" registry setting

- use less wildcards in search

- ... be creative :-) and find another workaround

But keeping it this way, You can never be sure, whether Your result is correct...