Hi Tom,
I am not happy that I have to do this now, but I think it is time "to wash your head". Cholerical attacks are not nice for you and others, but as I had several of your attacks over the last years I think it is time that you excuse yourself to me and others as I am not the only one. That's the minimum from my sight. So much about this theme.
I am sure others will agree.
If you would have read the text exactly, you would have noticed that 2 GB were only reported as a bug fix, not as a new feature. The old version only supported FAT16 and 2 GB, so 2TB are not only ONE but THOUSAND milestones!
I assume that you never tested command and kernel on a 2 TB virtual HD (on vmware you can also choose a bigger one, fdisk restricts itself to 2 TB). If you had, you would have noticed, that FD fdisk supports full 2TB, but format still does not support full 2 TB, only something a little below, but this makes it hard for USERS (like me) to understand the correct usage if fdisk says "this is the maximum size" and format gives an error message because this is too much size for it.
And strictly spoken it is not the debt of format, but of the kernel (I have a test version of the kernel where this problems does not occur and you can create real 2 TB).
The joke is, when I start the program, it looks for the size and does not change it while copying in about 2000 files. But at the end sometimes a size stays over and FD "dir" says that there is still free space. But it is even not possible to execute:
"echo This is Toms excuse > excuse.txt". The command simply hangs.
Then shutting down the machine and rebooting it again a simple "dir" says: 0 Byte free. Simply test it. You only need VMware or virtual box that needs less space for an empty 2 TB HD and a lot of time. But it does not always happen. So I reported this to Eric. Tests like this are not my first tests! And most of them were correct.
And: it is no marketing blabla, I want to encourage the programmers to create working tools like chkdsk, dosfsck, defrag etc that really work on 2 TB. Otherwise it would be better to remove the FAT32 feature out of FD again. And in my eyes it would be a disgrace to distribute a version 2.0 without this features.
Sorry, but I think this had to be said.
Willi
Sent: Sunday, February 09, 2025 at 4:33 PM
From: "tom ehlert via Freedos-devel" <freedos-devel@lists.sourceforge.net>
To: "Technical discussion and questions for FreeDOS developers." <freedos-devel@lists.sourceforge.net>
Cc: "tom ehlert" <t...@drivesnapshot.de>
Subject: Re: [Freedos-devel] ZEROFILL R2.01 Released (was ZEROFILL R2.00 Releas ed)
From: "tom ehlert via Freedos-devel" <freedos-devel@lists.sourceforge.net>
To: "Technical discussion and questions for FreeDOS developers." <freedos-devel@lists.sourceforge.net>
Cc: "tom ehlert" <t...@drivesnapshot.de>
Subject: Re: [Freedos-devel] ZEROFILL R2.01 Released (was ZEROFILL R2.00 Releas ed)
Hallo Herr Fritz Mueller via Freedos-devel,
am Sonntag, 9. Februar 2025 um 13:48 schrieben Sie:
> Hi Eric, hi all,
>
> I am happy to inform you that Nikkho published version 2.0.5 of ZEROFILL.
> It fixed a lot of minor bugs, among others it was unable to write more than 2 GB with FD and
> if you delete the zerofile files it shows that they are deleted (in older versions you could not
> see that it deleted files and you had the feeling that it crashed).
Nice. However correctly handling 4GB+ disks correctly might be expected from a 2.0.5 utility.
> I tested it several times in virtual machines, and it works fine! With vmware you are even
> able to mount a real existing HD and to write inside with zerofill! (Be careful, vmware does
> not ask you for drive letters, but for HD numbers first, later for the partition that you want
> to use - and vmware needs admin rights. Of course you need FAT32.)
> Interestingly vmware was writing much faster than virtualbox. Even working with virtualbox
> and vmdk was slower.
>
> What most of you will overlook:
> Zerofill is the FIRST FD tool that really handles a 2 TB formatted HD!
While I haven't tested COMMAND on a 2 TB disk, I expect it to report free disk space correctly. For more then 10 years.
> Neither chkdsk nor dosfsck, defrag etc. do this till now!
They are an entirely different class of utilities.
> So ZEROFILL is a milestone in supporting big HDs by FreeDOS. CONGRATULATIONS, Nikkho!
Please spare us this marketing BLA. Fixing bugs is nice, but doesn't make the 'milestones'.
Tom
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
am Sonntag, 9. Februar 2025 um 13:48 schrieben Sie:
> Hi Eric, hi all,
>
> I am happy to inform you that Nikkho published version 2.0.5 of ZEROFILL.
> It fixed a lot of minor bugs, among others it was unable to write more than 2 GB with FD and
> if you delete the zerofile files it shows that they are deleted (in older versions you could not
> see that it deleted files and you had the feeling that it crashed).
Nice. However correctly handling 4GB+ disks correctly might be expected from a 2.0.5 utility.
> I tested it several times in virtual machines, and it works fine! With vmware you are even
> able to mount a real existing HD and to write inside with zerofill! (Be careful, vmware does
> not ask you for drive letters, but for HD numbers first, later for the partition that you want
> to use - and vmware needs admin rights. Of course you need FAT32.)
> Interestingly vmware was writing much faster than virtualbox. Even working with virtualbox
> and vmdk was slower.
>
> What most of you will overlook:
> Zerofill is the FIRST FD tool that really handles a 2 TB formatted HD!
While I haven't tested COMMAND on a 2 TB disk, I expect it to report free disk space correctly. For more then 10 years.
> Neither chkdsk nor dosfsck, defrag etc. do this till now!
They are an entirely different class of utilities.
> So ZEROFILL is a milestone in supporting big HDs by FreeDOS. CONGRATULATIONS, Nikkho!
Please spare us this marketing BLA. Fixing bugs is nice, but doesn't make the 'milestones'.
Tom
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
