From: MORRIS@PATRICK-PIMS.AF.MIL ("Jay Morris")
Newsgroups: comp.os.vms
Subject: RE: Wrong version number assigned
Date: 14 Oct 92 12:42:00 GMT
Article-I.D.: ucbvax.9210141220.AA12486
Distribution: world
Organization: The Internet

{As usuall, when you're too close to the problem, you forget that others don't
know the details}
{lrw> is <leichter@lrw.com>}
{me> is orginal post}
me>						   Occasionally I have a
me>	problem with file version numbers being wrong.  As I have noticed it
me>	most often with FTP, I will use that as an example.

lrw>There are at four common TCP/IP implementations for VMS, plus most likely
lrw>other less-common ones, each with its own FTP.  You'll have to be more
lrw>specific ....

I'm using Wollongong.

{details ommited on FTPing file from another system.}

me>	Do dir.  Now have two versions again. ;1 and ;2! With ;1 being the
me>		last complete file!
me>	Hopefully awake enough to recognize disparity and not do PURGE but
me>		delete ;2

lrw>It's not hard to explain how this might happen.  I'm assuming the other end is
lrw>also a VMS system.  I think what's going on is that the final transfer is
lrw>using the full specification of the remote file, including the version number.
lrw>That version number happens to be 1, so you get a new version 1, along with
lrw>the old version 2.

Sorry, other end is a Unix system.  Good thought through. I think I will set up
a test case on with a VMS system through, just to see.

lrw>How, then, did you get a version 2?  Perhaps the earlier transfer was done
lrw>with a slightly different FTP command - MGET vs. GET, explicit output spec
lrw>vs. fully defaulted, who knows.  Or perhaps your FTP is being too clever:
lrw>It tries to preserve the file version number, but if it gets a conflict for
lrw>the specific version it needs, it creates a new version of the file.  The
lrw>only way to find out - since such stuff is rarely documented in full detail -
lrw>is to try some experiments.

me>	I have seen this problem when editing a file where it will start over
me>	with ;1 and I think it happened with rename once.

lrw>All it takes is an explicit ;1 on the output file.  I know of no way for it
lrw>to happen without that - and I've never seen it happen without that.

Nope, did not ever specifiy a version number. Not an explict ;1 or ;0 or ;-1 or
anything.

me>	Yes, I have double, triple and quadupled checked.  The filenames are
me>	the same.  I even did a purge by the filename, and all that was left
me>	was the lastest incomplete one.  Here is an example.

me>	REDUNTENTA.LIS;2        186  12-OCT-1992 22:06:32.89
me>	REDUNTENTA.LIS;1        313  12-OCT-1992 22:11:40.28
me>                                  ^^^^^^^^^^^^^^^^^^^^^^^
me>	Sure looks like to me that ;1 is a later version than ;2.  

lrw>Nothing in VMS guarantees that the highest version number belongs to the most
lrw>recent version of the file.  However, as long as you create files by handing
lrw>the file system a file spec without a version number, or with a version number
lrw>of just ";", it will create a new version higher than any existing one - and
lrw>indeed the versions will be ordered in time.

Well, I gave up expecting any kind of guarantee on software a long time ago
(terrible thing for an SE to say!).  But I am not specifying the version.  

me>	So, does anyone else see this problem? or should I just cut back on
me>	the caffine?

lrw>There MIGHT be some odd corner in your FTP's file spec handling, but my bet
lrw>is "foot on gas, not brake".
lrw>							-- Jerry

How did you kwon I tyep wthi ym feet?

jay
morris@patrick-pims.af.mil
Newsgroups: comp.os.vms