Hasleo Software Forums

Feature request - have a way to see the current version number of the program from the main window and/or display it on the start-up splash window.

(06-21-2024, 10:12 PM)RobLatour Wrote: [ -> ]Feature request - have a way to see the current version number of the program from the main window and/or display it on the start-up splash window.

Thanks for the advice, we'll do it.

(06-22-2024, 12:05 AM)RobLatour Wrote: [ -> ]

(06-21-2024, 10:50 PM)admin Wrote: [ -> ]

(06-21-2024, 10:12 PM)RobLatour Wrote: [ -> ]Feature request - have a way to see the current version number of the program from the main window and/or display it on the start-up splash window.

opps, I just noticed if you go to the little icon beside the minimize button, and check for update you get the version number of the program - so I guess it is there - just a little hidden.   But still might be worth adding to the splash window.   Thanks
Thanks for the advice, we'll do it.

We will display the version number in the title bar.

Please add ability to install/update via WinGet

many thanks

(06-26-2024, 03:55 PM)redtreetop Wrote: [ -> ]Please add ability to install/update via WinGet

many thanks

I'm sorry we're not familiar with WinGet, we'll consider it in a future release. Thanks.

It would be nice is HBS could disable TRIM on an SSD when an image is being created or written to, and then enabled again when the reading/restoring is completed.

N8, I'm curious, why would you want this to happen?  If TRIM is disabled during restoration then all the blocks in the SSD being restored to would be left orphaned and unavailable to the FileSystem under Windows (unless the garbage collection algorithm used by the SSD is smarter than most... they're all different).  If anything, the TRIMming of the blocks being restored, prior to restoration (the way Macrium REFLECT does it), guarantees no orphaned blocks caused by the restoration by itself.  Under any case, following the restoration (having used no TRIM), any periodic optimization by the OS after the restoration would free up those orphaned blocks anyway, unless the user never optimizes their disks during normal operation.  That would result in tons of orphaned SSD blocks that would eventually affect (slow down) SSD throughput.

As far as TRIMming the image target during the imaging operation, that doesn't make any sense at all due to the way Windows allocation and TRIM actually operate... not really a requirement here.

It was my understanding that having trim enabled during a restore can mess with proper 4k partition alignment. I could see your point, but partition alignment remains an issue. It's also worth noting that disabling trim before image creation is important because it reduces the amount of caching required for the source drive on systems with TRIM enabled by disabling TRIM during the backup operation. When TRIM is enabled the original contents of deleted sectors must be cached, whereas a normal delete doesn’t overwrite the sectors and instead just updates the directory entry.

But that's just me. Maybe I've been using IFW too long.

(07-15-2024, 03:58 AM)n8chavez Wrote: [ -> ]It was my understanding that having trim enabled during a restore can mess with proper 4k partition alignment.  I could see your point, but partition alignment remains an issue.  It's also worth noting that disabling trim before image creation is important because it reduces the amount of caching required for the source drive on systems with TRIM enabled by disabling TRIM during the backup operation. When TRIM is enabled the original contents of deleted sectors must be cached, whereas a normal delete doesn’t overwrite the sectors and instead just updates the directory entry.

But that's just me.  Maybe I've been  using IFW too long.

Referencing the RED:  Now you've got me really confused    I've never heard of TRIM ever causing a 4K (I assume sector size here) sector-based partition problem.  It may have but I've been part of many discussions in this area and have never heard of such.

Referencing the GREEN: Something else I've never heard of.  Reducing Windows caching doesn't really affect the reading of the SOURCE drive in any major way other than possibly slowing up an older slower drive in its READ operation.

Referencing PURPLE: I think this statement is caught up in semantics between the SSD itself and the Windows operation.  What you're describing is basically what happens inside the SSD, not anywhere in Windows.  If TRIM is disabled in the SSD then the SSD will not clean up the old data being replaced during the write operation (aka "caching")... that's what I was referring to in my post above, that data will be orphaned inside the SSD until told to clean it up.  TRIM is the only way to do that cleanup, other than through some garbage collection algorithms.  None of this stuff affects the efficiency of your Windows operations... they are very straight forward as far as DELETE and TRIM are concerned.

The normal delete you describe above is, indeed, a Windows operation, but it never overwrites anything regardless of TRIM.  The way the DELETE operation works under Windows is as follows... the old method, does indeed update a directory entry as well as clear allocation blocks used in its FAT (File Allocation Table), that's all it needed to do.  When TRIM was introduced, it needed to be able to tell the SSD when its internal NAND memory was no longer needed.  What Windows decided to do was the same stuff it did with the older operations, but also send a special transaction to the SSD (via TRIM) that told the SSD what blocks were no longer needed... Windows was done at this point.  The SSD then, internally, would free up its NAND blocks by moving the data around and placing it in empty NAND blocks (a very efficient pure WRITE operation), basically filling up the empty blocks.  At this point, the SSD can now ERASE any NAND blocks that are no longer needed.  The most efficient operations within an SSD is a READ, WRITE & ERASE.  If the SSD cannot find any absolutely empty (unallocated) NAND blocks to use for this internal recovery, it then must rely on another very inefficient operation, the READ-MODIFY-WRITE (RMW), to enter data into the unused portion of existing non-empty NAND cells.  This is why if TRIM is not enabled over a longer period, eventually all those orphaned BLOCKS must be used for writing data, but can only be used with the RMW operation, which really slows down an SSD immensely.

The whole SSD internal operation is a complex one (it has its own "logical block" table similar to Windows and its own FAT table to represent what its NAND cells are really doing) and really doesn't reflect at all what Windows is doing.  Any major discussion of this type of operation should be be held elsewhere, not really in the Forum