maximum file version number

[Nick Briggs]

In fixing issues around the version number handling in Maiko I switched to processing the version numbers purely as text, taking out text-to-integer and integer-to-text conversions that were being used only to remove leading zeros. The result is that the Maiko code can handle version numbers up to the length of the text buffer it works in.
However, it turns out that the FileBrowser stores file versions in a WORD (16-bit) field -- so while you can (OPENSTREAM "{dsk}<tmp>test.txt;65539" 'OUTPUT 'NEW) and get the expected result, if you then FB {dsk}<tmp>test*.* -- it will fail with an illegal argument in FB.CREATE.FILEBUCKET when it tries to store the version. This has probably been the case forever, since the original Maiko code used 999999999 as a flag for the end of the version number list for files it processed.

I'm not convinced that

(a) this is worth fixing in the FileBrowser code (I suspect even Ron isn't going to generate >64K versions of a file)
(b) this needs to be range-checked in the Maiko code (or what to do if a larger version number is found)

but I'd be interested in other opinions.

-- Nick

[pixel...@gmail.com]

So it would seem like users should avoid encoding metadata like edition date into the revision number. :)
If you edited a file 10 times every day you'd get just under 18 years. (assuming 65535)

I wonder how high the numbers actually got in practice with people very seriously hacking on their projects.

[Ron Kaplan]

One of the Tedit files in my working directory is version 867

-- 
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/e088a0a0-c6e5-4f2f-a649-9b1c6087e0dbn%40googlegroups.com.

[Nick Briggs]

On Oct 17, 2025, at 16:28, pixel...@gmail.com wrote:

So it would seem like users should avoid encoding metadata like edition date into the revision number. :)
If you edited a file 10 times every day you'd get just under 18 years. (assuming 65535)

Correct. The file versions were automatically incremented by one each time you wrote a new version of the file, and the limit on the file version was probably there in the IFS implementation - on TWENEX systems the limit was 131071 (36-bit machine, signed 18-bit number for the file version, so 2^17 - 1).  I don't know of anyone who abused the version numbers like that.

I wonder how high the numbers actually got in practice with people very seriously hacking on their projects.

I'd guess a few hundred, probably not over 1000, and (in the past) when you released a new version from your local disk working space to the file server it would be +1 from the previous version on the file server.

As Ron just pointed out, he's got a version 867.

On Friday, October 17, 2025 at 12:58:03 PM UTC-6 nicholas...@gmail.com wrote:

In fixing issues around the version number handling in Maiko I switched to processing the version numbers purely as text, taking out text-to-integer and integer-to-text conversions that were being used only to remove leading zeros. The result is that the Maiko code can handle version numbers up to the length of the text buffer it works in.
However, it turns out that the FileBrowser stores file versions in a WORD (16-bit) field -- so while you can (OPENSTREAM "{dsk}<tmp>test.txt;65539" 'OUTPUT 'NEW) and get the expected result, if you then FB {dsk}<tmp>test*.* -- it will fail with an illegal argument in FB.CREATE.FILEBUCKET when it tries to store the version. This has probably been the case forever, since the original Maiko code used 999999999 as a flag for the end of the version number list for files it processed.

I'm not convinced that

(a) this is worth fixing in the FileBrowser code (I suspect even Ron isn't going to generate >64K versions of a file)
(b) this needs to be range-checked in the Maiko code (or what to do if a larger version number is found)

but I'd be interested in other opinions.

-- Nick