On 25 Nov 2005 at 15:55, Craig Lalley wrote:

>   :LISTFILE /BACKUPS/PUB/,2  
> 
>   is just one....

This is how I discovered the "missing" files to begin with.  I do not 
wish to appear obtuse on this matter, and I recognize from the outset 
that this behaviour is never going to change, but I believe that the 
choice of invisibly moving file equated references into the posix 
namespace betrays a lack of consideration for the end user 
breathtaking in its presumption.

Personnel accustomed to running HP3000s wholly in the traditional 
manner of file.group.acct are not likely to even conceive of 
structuring a file query in the fashion above and are probably using 
LISTF to begin with.  My goal is to enhance the recoverablity of 
these systems in the event of a major failure and the possibility of 
my absence.  Forcing the POSIX namespace conventions on staff who 
have only a rudimentary, rote-based, knowledge of MPEiX does not, in 
my view, enhance the already slim possibility of that goal being 
achieved.  

These are backup files!  I want you to imagine under what conditions 
a user is likely to be searching for them.  Do really think that this 
design choice promotes the likelihood of a speedy recovery?  Imagine 
the comments if Microsoft had written their disk backup utility so 
that all disk archives could only be stored in a special directory 
structure on NTFS volume that used a naming convention of 
file.subdirectory.root and were invisible to common DOS commands or 
the usual windows explorer in consequence.

My basic point of contention is that if one has more than 4 Gb of 
data to store in a single disc archives then one is compelled by HP 
CSY design decisions with respect to STORE's implementation of S-T-D 
to work in the POSIX namespace without exception.  There is no way 
around this.  To a common user the files simply disappear.  From the 
point of view of scripting, existing methods have to be significantly 
revamped.  These are needless complications that could have been 
avoided by preserving the creation of all STD files in the MPEiX 
namespace.

I realize that there were probably sound technical reasons for 
implementing STD in the fashion chosen, but it is really not a 
satisfactory solution from the standpoints of ease-of-use, 
transparency, consistency, or backwards compatibility.  POSIX was 
never, to my understanding, meant to supplant MPEiX.  STORE's 
behaviour is evidence that I clearly misapprehended the actual case.

Regards,
Jim

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *