[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