An user reported that one large SAVF of his could not be opened by jSAVF.
After investigation it appears that one of the SAVF index items was too big and split by the iSeries into several additional ones, which jSAVF didn't know how to handle.
I am unsure whether this is due to the recent version of the OS the SAVF was made on (V7R3), but now jSAVF can handle such SAVF.
I have also changed the way jSAVF is released to keep up to date with the new Java versions.
jSAVF is now compiled against Java 11, and requires such an environment to run.
I recommend using OpenJDK 11 instead of Oracle's commercial version of Java 11 due to changes in Java licensing.
jSAVF will be available in two formats:
An archive including the JAR files for each of jSAVF module or dependency, and a script to help start it for Windows or Linux.
An NSIS Installer for Windows (x64), which includes the jSAVF modules and dependencies, and the minimal modular image of OpenJDK to run it, built using jlink.
So the choice really comes down to whether you want to install the Java environment yourself or not.
If you encounter any trouble with this jSAVF version or cannot open a SAVF with it, don't hesitate to report it to me.
BugFix: DriveSort 1.242
This version fixes two file list scrolling bugs which affect the DriveSort's playlist mode:
The first bug prevented the list from automatically scrolling up or down when you were dragging a file above or below the files currently visible in the file list, which made manually sorting folders with many files a pain. It was due to DriveSort's use of an up or down scroll increment with a number of pixels which was smaller than the list line height, which was rounded down to zero lines by the list view control and thus lead to no scrolling at all.
The second bug made the list scroll back up to the first file when a file was dropped in its new position. I've fixed it so the files currently in view before the drop stay displayed after the drop.
Thanks to the user who reported the scrolling issues.
BugFix & Update: DriveSort 1.240
This version fixes a small bug in the user preferences loading code which prevented DriveSort from remembering you chose the new logical long name comparison
base in a previous execution of DriveSort. In this case, at startup DriveSort was switching to a comparison by file size.
Thanks to the user who reported it.
Another user asked for an indication of when DriveSort was working and done, so this version also shows some progress when sorting folders and
when saving the sorted folders to disk.
The sorting operation is usually rather fast, but the saving operation can take a while when processing many folders on slow peripherals.
When sorting or saving, DriveSort now displays the current operation in the status bar at the bottom and turns the mouse cursor into a wait cursor.
When it's saving it also displays in red in the progress bar how many directory entries it has saved.
Update: DriveSort 1.231
In response to some user needs, this version brings three changes:
A new comparison base in the menu next to the sort icon allows to sort files by their logical long name, which is useful when working with files or
folders which contain numbers as is often the case for music tracks.
Before, when sorting a list of files named 1-1, 2-1, 5-1, 8-1, 8-2, 8-10, 10-1, 13-1, 20-1 using the long name as comparison base, the list was sorted
lexicographically (1-1, 10-1, 13-1, 2-1, 20-1, 5-1, 8-1, 8-10, 8-2) which doesn't feel right.
By padding the numbers with zeroes on the left, it was possible to work around the issue to obtain the correct order (ex: 01-1, 02-1, 05-1, 08-01, 08-02, 08-10,
10-1, 13-1, 20-1) but that could become a chore.
With this new comparison base the files are now sorted in the more natural order of the numbers they include, as the Windows file Explorer does.
An user with an old AMD processor was no longer able to run DriveSort because the new compiler I'm using by default generates code which requires a processor
supporting the SSE2 instruction set. In order to be compatible with more machines, DriveSort is now compiled in a way which doesn't require these instructions
which it doesn't really need.
I don't have a non SSE2 machine at my disposal to test the compatiblity, but by having a quick look at the disassembled code there doesn't seem to be any more
SSE2 instructions in the generated code, so I hope this version will be compatible with more machines.
Usually administrator rights are required by Windows to lock a disk in exclusive mode and work with filesystems in the way DriveSort needs to.
An user nonetheless told me he managed to work with an older DriveSort version which didn't require administrator rights, and was now blocked from using the new
versions by the user account control because his account didn't have administrator rights.
There might be some situations where special priviledges might suffice, so in order to allow priviledged users without administrator rights to use DriveSort,
this version no longer requests administrator rights to start, but only the highest priviledges the user account has been granted.
For users whose account had administrator rights this changes nothing, DriveSort will still run as administrator.
For normal users, the lack of administrator rights should no longer prevent DriveSort from starting, but the absence of priviledges required by Windows should
still prevent exclusive disk locks, which should manifest itself as an error popup when opening a disk with an access denied message.
I've performed a few tests on a VM under Windows XP SP3 as User, Power User, or member of the Backup and Restore group, but without success.
If anyone manages to open a disk with DriveSort without administrator rights I'm interested to know how your user account is setup (maybe with secpol.msc?) and
under which Windows version this is supported, so don't hesitate to keep me posted.
Moreover, for more security DriveSort now attempts to enable for its process some more Windows security features and exploit mitigation policies on top of
those previously activated when they're available on the Windows version on which DriveSort runs. DriveSort now disables child process creation since it's not
supposed to run other programs, prevents the use of dynamic code since it doesn't generate any, disables the use of win32k.sys syscalls, and some other
extension points it doesn't use.
I could test this version on an up to date Windows 10 and a Windows XP SP3, but if you notice any compatibility issue don't hesitate to mention it to me.