A few suggestions

[thomas]

I'd like to see these in one of the next WinUAE releases:

- a newly created ADF should appear in the drop down list next to the floppy drives. This would come next to the hard drives panel where a new HDF immediately appears in the HDD list.

- option to create PC floppy images (720K / 1440K). Now that WinUAE supports these images for use with CrossDOS and the like, it should also be able to create them.

- support for 64bit packets in file system emulation for use with files bigger than 4GB. Currently they are only supported by SFS2. Would be níce to see them in NTFS directories, too. A sample 68k application and an extract from the OS 4.1 autodocs are attached.

[Toni Wilen]

- a newly created ADF should appear in the drop down list next to the floppy drives. This would come next to the hard drives panel where a new HDF immediately appears in the HDD list.

I'll think about it..

- option to create PC floppy images (720K / 1440K). Now that WinUAE supports these images for use with CrossDOS and the like, it should also be able to create them.

It (and me) does not know nothing about DOS logical format. It is emulated filesystem driver that only understands it.. (probably easy to do but too lazy to find GOOD example showing empty formatted logical FAT structure)

- support for 64bit packets in file system emulation for use with files bigger than 4GB. Currently they are only supported by SFS2. Would be níce to see them in NTFS directories, too. A sample 68k application and an extract from the OS 4.1 autodocs are attached.

Consider it done.

[thomas]

It (and me) does not know nothing about DOS logical format. It is emulated filesystem driver that only understands it.. (probably easy to do but too lazy to find GOOD example showing empty formatted logical FAT structure)

Oh, no need to create formatted floppies. Just add 3.5" DD (720k) and 3.5" HD (1440k) to the drop down list next to "create standard disk". It creates unformatted images, too, if you use "create custom disk", so it shouldn't matter.

[Toni Wilen]

Originally Posted by thomas

Oh, no need to create formatted floppies. Just add 3.5" DD (720k) and 3.5" HD (1440k) to the drop down list next to "create standard disk". It creates unformatted images, too, if you use "create custom disk", so it shouldn't matter.

In my opinion "native" (logical format-specific) images should be (logically) formatted.

Extended adf is completely unformatted because it is not logical format specific image.

[Toni Wilen]

How are >4G (or >2G if size is considered signed) files supposed to appear with regular 32-bit filesystem? (for example network filesystem, standard fs of course can't both support and not support >4G files )

Size truncated to 32-bits or are they shown as 2^32 - 1 (or 2^31 -1)? Or hidden completely?

EDIT: I guess limiting to 2^31 - 1 is good enough solution (size appears to be signed)

[thomas]

How are >4G (or >2G if size is considered signed) files supposed to appear with regular 32-bit filesystem?

I am not sure what you mean by ">4G files on a 32-bit filesystem". Every existing Amiga file system (except SFS2) will stop writing to a file when it reaches 2GB and issue an IoErr of "disk full" or something like this.

Size truncated to 32-bits or are they shown as 2^32 - 1 (or 2^31 -1)? Or hidden completely?

If you Examine() a big file on an SFS2 partition, fib_FileSize contains the lower 32 bits (i.e. a 9 GB file appears as 1 GB).

The same happens for a Windows share mounted with SMBFS.

I vaguely remember a discusion where it was suggested that you can get a quite good approximation of the real file size if you multiply the number of blocks with the block size and then replace the lower 32 bits by fib_FileSize. But I think this was only a question, not an official recommendation.

In my opinion "native" (logical format-specific) images should be (logically) formatted.

Perhaps you can use the code from the attached program. I made it by simple file comparisons, without any knowledge of the disk structure.

[Toni Wilen]

Originally Posted by thomas

I am not sure what you mean by ">4G files on a 32-bit filesystem". Every existing Amiga file system (except SFS2) will stop writing to a file when it reaches 2GB and issue an IoErr of "disk full" or something like this.

I mean what should happen if Windows directory has file >4G. Truncating to 32-bit looks stupid (exactly 4G file would appear as 0 bytes, 4G - 1 as -1 )

I still think limiting to 2G - 1 is most logical choice. (when not using 64-bit packets)

[thomas]

Originally Posted by Toni Wilen

I mean what should happen if Windows directory has file >4G. Truncating to 32-bit looks stupid (exactly 4G file would appear as 0 bytes, 4G - 1 as -1 )

That's exactly what happens if you use OS 3.1's List command on an SMBFS share which contains HDF files.

[Toni Wilen]

64-bit packets implemented in beta 15. Test please

[thomas]

The new packages, although working correctly, return an IoErr (dp_Res2) of -1. This should be 0.

The normal Seek() function should work inside the first 2GB of the file. It should only fail when trying to seek past the 2GB limit.

When using Examine() the fib_NumBlocks field should contain the correct value, even if you fake the fib_Size field.

[Toni Wilen]

Originally Posted by thomas

The new packages, although working correctly, return an IoErr (dp_Res2) of -1. This should be 0.

ok

The normal Seek() function should work inside the first 2GB of the file. It should only fail when trying to seek past the 2GB limit.

Should it still work if using relative seek? Or should it always return SEEK_ERROR if absolute seek offset is >=2G? (=return value would be >=2G)

When using Examine() the fib_NumBlocks field should contain the correct value, even if you fake the fib_Size field.

ok

[thomas]

Originally Posted by Toni Wilen

Should it still work if using relative seek? Or should it always return SEEK_ERROR if absolute seek offset is >=2G? (=return value would be >=2G)

It should return an error whenever the return value would be wrong (i.e. >= 2G).

[Toni Wilen]

What if read or write is called when file position is very close to 2G border and written/read data gets over border?

(too many corner cases, should I even care? )

[thomas]

Read and Write work normally everywhere in the file. There is no 64bit replacement for Read and Write. Read and Write don't return file position anyway.

If the new position after Read or Write is above 2G, a subsequent Seek will fail.

Note that Seek succeeds if you seek past the 2GB limit, but the old position (which is returned) was below 2GB.

Actually there is no corner case IMHO. If the return value of Seek is >= 2G, it fails. Otherwise it succeeds. As Seek returns the old file position, you can even check it before you execute the Seek.

[DH]

Suppose this is as good a place to add this suggestion as any, sorry thomas for hijacking your thread slightly.

When you select a disk image the file types always default to the standard Amiga Floppy disk images, this is great most of the time, but as I'm not loading in standard disk images, I need to keep selecting 'All files (*.*)' for everything I need to load up. Would it be possible to incorporate a feature into WinUAE to either remember the last selection or add a switch into the load image file screen, so the user has the option to switch it on or off.