Hm... the only thing that <100> could be if this is saveset cut off size issue where after each 2GB you get one for same ssid. That used to be a bug with early 7.3.x code or if your client is using some really older code.

I can't see that with 7.3.3 (didn't try 7.3.2). In my case output is slightly different:

hcrvelin.002.RO
hcrvelin
11/11/2007
51 KB
C:\Documents and Settings\Hrvoje Crvelin\



So I get impression that it was not just -xm. I get ssid when using verbose output. Simply remove -x to see what that would be in real life, but I agree that <100> in your example is extra. Try 7.3.3.

Thanks for the response. The client and server are both running 7.3.2.

In addition, this doesn't quite match the explanation for <100> you posted. Here's a little more context (should have provided in the first place):

# mminfo -xm -r 'volume,client,ssid,nsavetime,cloneid,level,pool,name' -q ...
...
000162L3
host
238298420
1194599570
1194599570
full
Pool Name
/save/set/path


000162L3
host
2788443345
1194599670
1194599570
full
Pool Name
<100>/save/set/path


000162L3
host
2771666222
1194599671
1194599570
full
Pool Name
<101>/save/set/path

...

IOW, I get an initial saveset without the <100>, then a bunch of savesets with that prefix. All of these have distinct ssids, but, curiously, the same cloneid. They do, however, have sizes of 2GB (actually 2000MB), as you suggest. In the particular case I'm looking at, there are 118 of these savesets.

I'm actually trying to generate a report of what needs cloning, but this has me pretty confused. Do I need to clone each of those distinct ssids to clone the saveset properly? or only the ssid for the saveset that has no ?

Will try 7.3.3 soon, but I wonder if anyone else has already dealt with this question.

I've done some experimenting. It appears if one clones the first saveset in the "series", i.e. the one with the saveset name that does not contain , NetWorker automatically clones the entire series:

# nsrclone -v -b 'Clone Pool Name' -S 238298420
nsrclone: adding save set series which includes parent 238298420
Automatically copying save sets(s) to other volume(s)

Starting cloning operation...

In addition, the pssid attribute in mminfo is documented to be 0 for the first or only saveset in a series. Adding "pssid=0" to the mminfo query clause appears to eliminate all the results.

That's a bug (but not in mminfo). You should get to 7.3SP3 as soon as possible. It seems as for some reason NW reverted to very old mechanism in your case (5.x era) and I remember in some instances it was also caused by auth model apparently (lovely nsrauth so you may check that too).

To be clear, there is a bug in mminfo's XML output writer. Regardless of whether the saveset segments should have in them, one can always create savesets with arbitrary names, so the XML output writer needs to escape < and >.

I would be interested to know whether this bug persists in 7.3.3. I.e. if you do "save -N ' ' [options] /path" does mminfo -xm still produce broken XML when writing the saveset name?

To answer your question:

C:\Documents and Settings\Hrvoje Crvelin>cd \
 
C:\>save -N " My test" *.bat
save: Using hcrvelin as server
C:\nw_start.bat
C:\nw_stop.bat
C:\ruta.bat
C:\unruta.bat
C:\
/ 
 
save:  My test  4 KB 00:00:03      6 files
save completion time: 11-12-07 12:50p
 
C:\>mminfo -t today -r volume,client,ssid,nsavetime,cloneid,level,pool,name
 volume        client     ssid         save time   clone id  lvl pool          name
hcrvelin.002   hcrvelin   3685878     1194868214 1194868214      Default        My test
hcrvelin.002.RO hcrvelin  3685878     1194868214 1194868213      Default        My test
 
C:\>mminfo -t today -r volume,client,ssid,nsavetime,cloneid,level,pool,name -xm | findstr bzz
 My test
 My test

However, I'm quite sure if you check with support you will get an answer that both < and > are not valid characters for saveset name thus this is acting as expected and that what you ask should be seen as future RFE (and not sure if would be expected even I see no reason why now). This desirable behavior would be to have any after tag marker converted to standard HTML tag.

I don't know why you would think < or > are invalid characters for a saveset name. From the save man page:

-N name
The symbolic name of this save set. By default, the most common prefix of the path arguments is used as the save set name. If the -N option is used when saving any of the SYSTEM save sets (SYSTEM STATE, SYSTEM FILES, and SYSTEM DB), the path must also be specified and must match the name value assigned with the -N option.

If I save a path that has a < or > in it, that will be part of the saveset name by default. And there's nothing in the man pages that suggests that a "symbolic name" for a saveset has a restricted range of characters.

BTW, thanks for testing on 7.3.3. :^)

Fascinating. And here are a few more things that you can't do on Windows but you can do on a real operating system:

/tmp# mkdir ''
/tmp# ls -ld ''
drwxr-xr-x    2 root     root         4096 Nov 12 23:20 
/tmp# mkdir 'lpt:'
/tmp# ls -ld 'lpt:'
drwxr-xr-x    2 root     root         4096 Nov 12 23:27 lpt:
/tmp# mkdir 'x:\foo'
/tmp# ls -ld 'x:\foo'
drwxr-xr-x    2 root     root         4096 Nov 12 23:27 x:\foo
/tmp# mkdir '^A'    --- that's a literal control-a character
/tmp# ls -ld 'a^Ab'
drwxr-xr-x    2 root     root         4096 Nov 12 23:30 a?b

Starting to get the idea?



Not all of us have the freedom to dictate a tiny Windows-centric subset of valid characters for path names. And fundamentally, just because one particular operating system doesn't allow you to create a file with a given name is no reason for Legato to restrict symbolic names in savesets.



Updating to 7.3.3 doesn't solve the problem. The solution to the problem is for mminfo to emit correct XML. That means rewriting a number of characters as equivalent entities.

For now, I've worked around it with sed.