TeraByte Unlimited

When you have more than one file created for an image set, Image for Windows (and I assume DOS & Linux) creates files with extensions of .1, .2, .3, etc. For me this was rarely a problem, either because (back in the day) if I created multiple files, each the size of an optical disk (be they CD, DVD or BD), I would label/number the disks manually, so how the file numbering looked wasn't that important. Later on, when backing up to another large storage device, I normally created image sets of maximum size, so the number didn't exist. Or if I did limit the file size, there were still relatively few numbers.

However, now that I am starting to store my backups in the cloud, many services have limits to the size of each file, so I'm back to creating multiple files, and having the numbering as-is means the sorting by extension causes things to be displayed in non sequential order (.1, .10, 11, 12... .19, .2, .20, 21... .29. .3, .30. 31, etc.).

If the user had the option to pad the extension numbers with leading zeroes (.001, .002, .003... .010, .011, - you get the idea!) then the proper sorting would work again.

I'd suggest that the user be given both the option to include leading zeroes, as well as specify the minimum number of digits the extension should have. By having this as a MINIMUM number, the system will still work if a 2 digit minimum setting exceeds 99 files - the sorting will still be off for that set, but the backup will continue with .100, .101, etc. (and the next time the user may change to a 3 digit minimum).

Not something that needs to be immediately implemented, but I think it would be a useful feature.

Anyone else like this suggested option?

the original reason is to not to conflict with the old .img files (at least
to 100).

"Muad'Dib" wrote in message news:15218@public.image...

However, now that I am starting to store my backups in the cloud, many
services have limits to the size of each file, so I'm back to creating
multiple files, and having the numbering as-is means the sorting by
extension causes things to be displayed in non sequential order (.1, .10,
11, 12... .19, .2, .20, 21... .29. .3, .30. 31, etc.).

If the user had the option to pad the extension numbers with leading zeroes
(.001, .002, .003... .010, .011, - you get the idea!) then the proper
sorting would work again.

TeraByte Support wrote: "the original reason is to not to conflict with the old .img files (at least to 100)."


Could you please explain your comment in more detail (or provide a link that will do so)? I have no idea what you are referring to (I've been hanging with DrTeeth for too long, many of my brain cells are fried). Thanks.

the prior 1.x version used .001, .002.


"Muad'Dib" wrote in message news:15225@public.image...

TeraByte Support wrote: "the original reason is to not to conflict with the
old .img files (at least to 100)."


Could you please explain your comment in more detail (or provide a link that
will do so)? I have no idea what you are referring to (I've been hanging
with DrTeeth for too long, many of my brain cells are fried). Thanks.

TeraByte Support wrote:
> the prior 1.x version used .001, .002.

IFW's last v1 release was in March of 2007 (DOS & Linux v1's even earlier)! Don't you think it's been long enough to allow a legacy (and logical) method of numbering to be reinstated? I seriously doubt many (if any) people would confuse the two versions. Or, if you are committed to legacy support (a praiseworthy goal, I will admit), make the new extension FOUR digits long, or keep it three characters and make the first character an incrementing alpha, just something to make the files sort properly.

When you're looking at a large number of files that must stay together, you need to be able to easily detect if a file is missing, and a sequential display helps with that a lot. And sorting by timestamp doesn't always work, because some cloud services don't retain original timestamps (yes, that's their bad, but it's the way it is), and uploading (or downloading) doesn't always occur sequentially, so the new timestamps may be out of order.

On Wed, 4 Jul 2018 08:08:32 EDT, just as I was about to take a herb,
Muad'Dib disturbed my reverie and wrote:

>I have no idea what you are referring to (I've been hanging with DrTeeth for too long, many of my brain cells are fried)

Just for the record, you haven't. I have standards and pick my company
VERY carefully! The fact is that most of your neurons are inhibitory
and you can only blame the lab in which you were conceived.
--
Cheers,

DrT

"If you want to find out what is wrong
with democracy, spend five minutes with
the average voter." - Winston Churchill

Is there a plan to "restore" the 3 (or even 4) digit extension to Image?

While it could be done fairly easily, it's more the complexly the user would
incur by having such an option since it would look one way with the option
and another way without. I just thought of a way that would ease that, so I
guess the option can be made available with the caveat that it may be
incompatible with prior versions.


"Muad'Dib" wrote in message news:16817@public.image...

Is there a plan to "restore" the 3 (or even 4) digit extension to Image?

Muad'Dib wrote:
> Is there a plan to "restore" the 3 (or even 4) digit extension to
> Image?

I have same question.please give any solution

Why change something that is working well?