Check this screenshot of NTFS if you don't believe me...
It's a Lacie Mobile 2.5 USB box, installed with a 10GB drive formatted just an hour ago in WinXP as NTFS. Then connected to my A1 frontpanel USB. Using giggledisk to find HIGH CYL as seen in screenshot,edited the mountfile as seen and mounted it with c:mount!
However I find quite strange it's working using USB without any patch.
The Sirion USB stack used in AmigaOS4 is, or at least was, available for AmigaOS 3.x as well and supported the obsolete TD64 commands for AmigaOS <= 3.1, but it was forgotten to disable them in the AmigaOS4 version. This bug was fixed a long time ago already in the AmigaOS4 version, but it seems it wasn't yet in the version included in Update4.
I did not say I wasn't believing you, because I do believe you. Just I was finding it quite strange, but joerg stated what I was guessing from the begining : the USB device was supporting both NSD and TD64... At least until update 4 (means, you'll have to use the Salass00's patch with the next OS4 version...)
@Salass00
I've been using it for more than 1hour and a half yesterday to listen to MP3's to have a frequent read access and I did not experienced a single quirk Well done !
I'will probably try this method of yours soon as well, one thing you could check is perhaps whether the display of my 4.5GB ISO's as 2.0GB in both AOS4 + DIR-OPUS has something to do with L:NTFSfilesystem or my OS4 installation?
edit: i guess this is some 32/64 bit limitation...so using TD64 will solve it?
edit: i guess this is some 32/64 bit limitation...so using TD64 will solve it?
No. TD64 is just for the lowlevel device i/o, it knows nothing about files or directories itself. If there is a problem with big files then this needs to be fixed in the filesystem itself because that's where it is.
but maybe this is also DOpus that limits itself to display file size to 2GB ? Don't know I don't have such big files at hand, nor I have a known supporting Filesystem (SFS2 for example) to test DOpus display...
Someone with the SFS2, a >2GB file and able to test which size DOpus reports ??
I missed that part of what he wrote (i.e. about using DOpus) but now you mention it I'd say it's likely part of the problem.
Anyway on OS3.x there isn't really any good way to find out the size of file that is bigger than 4GB. Seek()ing to the end of the file and back again doesn't work because the position you get is a 32-bit integer. ExamineFH() doesn't work either since the size field is also only 32-bit.
On OS4 there is GetFileSize() which returns the size of a file as 64-bit integer, and of course Change/GetFilePosition(), which are more or less 64-bit equivalents of the Seek() command.
The underlying filesystem will of course have to support the relevant 64-bit packets also for these to work...
In this case when 2GB+ files all show up as 2GB probably the filesystem is simply putting the biggest number that it can fit into a signed 32-bit. Probably a good idea too since a lot of programs will likely treat the filesize as signed.
first I launch the TD64patch (in the user-sequence) with something like this : Quote:
RUN <>C:TD64patch a1ide.device 1
a1ide.device is the device to patch (here internal A1 ide), 1 refers to the fact that I choosed to only patch the device for the unit I'll use for NTFS and that my PC HD is slave on the first port.
Then once it's okay I double click on the mountlist I defined using giggledisk (from the NTFS archive).