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.

Here is why:

C:\>mkdir 
The syntax of the command is incorrect.
 
C:\>mkdir ""
The filename, directory name, or volume label syntax is incorrect.
 
$ mkdir ""
mkdir: : No such file or directory
 
$ mkdir ''
mkdir: : No such file or directory

Having both in illegal characters section says enough to me and having worked with file systems I know that having something like that in name (there are tricks how to do it of course) is asking for trouble.

So stop complaining, it's bug in what I already explained and update to 7.3SP3. And disable nsrauth

Yah, I ran across these errors (and more) with mminfo's output. Rather than wait for a fix, I just switched to a more forgiving parser.

I was writing some utilities in Java, and tried several "permissive" xml parsers. JTidy didn't work very well, but I found tagsoup worked great...

Let me know if you want some sample code.

Thanks. As I say, I'm using sed for the time being to fix up the < and >. I'll file a bug with EMC sometime soon.

Also, I've found that nsrinfo -xm has the same problem. I'm surprised this hasn't been addressed by now.

I'm guessing that for anything above #x7f, mminfo and nsrinfo are also utf8-unaware.

They are aware.


No This really has nothing to do with UNIX vs Windows capabilities. As I said there are ways how to do it and there are even under Windows if you insist The thing is that you will find no vendor using this characters for their application files and at least for now I didn't meet any sysadmin who insisted on that. But if you say that's the way you work, that's fine by me.

You will fill bug, but you will get RFE - keep us informed on that.

Then don't trot out Windows filesystems limitations as if they prove anything. Legato does backups for a number of operating systems, and the limits of any one operating system do not define the limits of Legato's architecture.



The thing is that you will find, if you perform computer forensics or operate a data stewardship program, that you will receive files with all sorts of fun names, and your backup software has to handle it. In fact, Legato does handle it quite well; the problem is that the reporting tools don't emit correct XML. You can keep apologizing for that if you want, but it's pretty cut-and-dry for people who actually work with XML: if mminfo -xm and nsrinfo -xm emit XML with this declaration at the 1.0" encoding="UTF-8"?>

then the following document needs to be be XML, encoded in utf-8. Period. What the particular "vendors" you've worked with call their "application files", and what you can't do with mkdir under Windows, are completely, utterly irrelevant.



Funny thing--EMC has fixed (or tried to) a number of problems I've reported, whether they've characterized them as "bugs" or "RFEs". Is that not your experience?