No new file versions on lib$rename_file

[Dario Karlen]

Hi guys

I have a program written in Fortran and there I rename a temporary file into a new_file.ext. with lib$rename_file. Every time I'm renaming the file a new file version of the new_file.ext is generated, so far so good.
How can I prevent generating new versions? At the moment I delete the file version ;-1 at then end of the program, but at the end of the day I ve got a file version about several hundreds.
Thanks for any help or tip....
Dario

[Hein van den Heuvel · Accepted solution]

Hello Dario,

OpenVMS does not do the 'implied' delete like Unix/Windoze would. So you can not create two file with the same name and version number in the same directory.

The easiest would be to just deleted the old temp file before renaming/creating the new file. But I guess you want to keep the old file around 'just in case' as long as possible?

How about
rename new_file.ext;* old_file.ext
rename temp new_file.ext;1
all is well? delete old_file.ext.*

Rename is cheap. On more will not hurt.

How about renaming the old new_file even before the creation of the temp file?
Then you could create the temp file directly with the target name 'new_file'

Finally, what's the problem with a version number in the hundreds? The limit is 65K.
As long as you rename well before getting there it is just a number and can give you a nice little hint as to how often the process has been used.

Cheers,
Hein.

[Jan van den Ende]

Dario,

several ways to do it.

- $ SET DIREC/VERSION_LIMIT = for the directory that receives new-file.ext
Note that this WILL apply to all files going into that directory.

- after you created the first instance of the file:
$ SET FILE/VERSION= new_file.ext

I am not sufficiently fluent :-( in Fortran, but I would expect there to be a construct to achieve the version limit from within the language as well, or as a param to lib$rename_file; others may have more pertinent info on that.

hth

Proost.

Have one on me.

jpe

[Jan van den Ende]

Ha die Hein,

it is really not often that I can catch you in an (however minor) RMS msitake!

>>>
Finally, what's the problem with a version number in the hundreds? The limit is 65K.
<<<

Well, my experience does not go further than V7.3-2, but here it is MOST DEFINITELY 32K - 1 ( = 32767) !!

(just for grinns)

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Yes, oops. version limit is 32K.
It just _should_ be 64K = 65535.
The negative numbers are of course used for relative numbering, but that's just a parsing thing. Best I can tell the 16 bits on disk, in directory, storage of the version numbers could just as well be interpreted as an unsigned short.

Jan, how does your suggestion solve the problem?
If I read Dario's entry correctly then the program allready takes care of removing the excess files. The concern appears to be the high version number, not the number of versions. Admittedly a version limit as you suggested would probably make the program simpler.

Groetjes,
Hein.

[Jan van den Ende]

Dario & Hein,

>>>
At the moment I delete the file version ;-1
<<, & >>>
If I read Dario's entry correctly then the program allready takes care of removing the excess files.
<<<
Yeah, I missed the ;-1 bit.
So my answer really is not an answer to the original problem.

But that makes Hein's statement
>>>
Finally, what's the problem with a version number in the hundreds? The limit is..
<<<
all the more valid. Wether 32 or 64 K, yyou still need in the order ot 100-ish sessions before reaching the limit.
And if (better: nearly), then one simple rename cures all.

A Dutch proverb more or less translates as:
"The foam is not worth the coals used"

fwiw

Proost.

Have one on me.

jpe

[Walter Miller_1]

After you delete the version;-1 you could always rename the file again using file.ext;0 file.ext;0.

[Dario Karlen]

Hi guys

Thank you for your answers.
jep, the problem is not the amount of files, but the high file version.
I ll try with the renaming you suggested.

thanks a lot guys.