[Info-vax] Is there a way to enabling versioning in Samba

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Mon Jul 24 18:11:59 EDT 2017


On 2017-07-24 21:26:35 +0000, Jan-Erik Soderholm said:

> Den 2017-07-24 kl. 23:08, skrev Stephen Hoffman:
>> On 2017-07-24 20:34:40 +0000, Jan-Erik Soderholm said:
>> 
>>> Then blame the craftsman, not the tool.
>> 
>> I'd rather understand the question and the situation, understand some 
>> of the alternatives, and work toward an appropriate way forward.
>> 
>> Some developers are just unfamiliar with the available tools and 
>> alternatives, or they've made very different trade-offs for their 
>> environments.
>> 
>> Or the folks phrase their questions in unexpected ways.   Or with old 
>> assumptions still latent in the questions or the requests.
>> 
>> File versions are another bit of arcana that new users get to learn. 
>> Though certainly familiar to experienced OpenVMS users, I've yet to 
>> meet a situation where a file version is a particularly good solution 
>> (as compared with other approaches and other platforms), and rolling 
>> the file versions is an oft-overlooked detail around ensuring 
>> application stability.      Missing the app- or environment-specific 
>> roll-over processing or using ;32767 to disable certain operations is 
>> quite common among experienced users, of course.  But how many of us 
>> have worked with apps that lack this?
>> 
>> But blaming the people involved?  That's seldom a good way forward.
>> 
>> As for the tools?   Using Samba is problematic on OpenVMS for various 
>> reasons, beyond the insecurity of SMB1 and any (lack of) OpenVMS file 
>> version handling.
>> 
> 
> But why try to look at file versions (as they are implemented in 
> OpenVMS) as a "solution" for something?

Ask the OP?   You're clearly certain what the question was.   I'm less 
certain, given some of what I've encountered.

As for using file versions?  Maybe because folks do try to use file 
versions for various reasons?   Yes, most folks tend to ignore file 
versions in their apps, or work within the constraints of the approach 
or use the occasional ;32767 hackery, and it all usually works.   
There's no standard or automatic framework for rolling over, in-build 
maintenance (/KEEP, et al) is a very simplistic design, and the 
implementation of logging and operator communications — cases that 
commonly accrue file versions — are comparatively limited on OpenVMS.

Like anything else, there are always trade-offs.  Sometimes the 
trade-off is because the folks are unfamiliar with the alternatives, 
sometimes because of budgetary reasons, sometimes politics, sometimes 
just because it's always been done that way or always been that way.   
The trade-offs can change over time, or over scale, too.  Sometimes 
it's because the platform doesn't have alternatives (yet?), and folks 
become inured or inculcated in a particular approach or particular 
solution.   (This whole area can become a discussion of software 
enhancements and upgrades and migrations, too.)

> It is just a feature that is there and it is sometimes quite nice.

File versions are usually more work than they're worth, as compared 
with other alternatives on other platforms.

That's if the file versions are not something simply ignored, or 
occasionally left to trigger arcane failures at inopportune times.

> I do not understand what you are after, would you rather prefer that 
> the file version feature in OpenVMS is removed altogether in a future 
> release?

Compatibility means that these sorts of features are left around for 
the foreseeable future, even if some particular current or future file 
share or file system might lack file versions.   Upgrades might lead to 
something akin to the file shares that have been available in some 
products (e.g. IBM Rational Clearcase VOBs, and which lead to 
discussions of adding FUSE support on OpenVMS), or the integration of 
DVCS tools or otherwise.  Or whatever else VSI can implement that draws 
in new users and/or encourages continued support purchases or upgrade 
interest.

I use file versions.   Mostly because they're on by default.  I also 
use other tools.    I'd prefer much tools other than file versions, 
too.   Other folks use file versions differently than I do.   I'm aware 
of a number of folks that use file versions and/or parallel directories 
— the traditional presentation of the OpenVMS file system — as their 
source code control, too.

Alternatives to Samba due to the insecurity of SMB1 and other issues 
are also a consideration for folks, beyond whatever use for file 
versions might be made within particular apps.  Different trade-offs, 
environments, etc.



-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list