Describe the bug
When using the C64 Ultimate's built-in file browser to copy some files from one storage medium to another (for example going from USB0 to SD), if a filename contains a dot, the portion after the dot gets truncated to three characters as if it's a traditional filename extension, which results in a file copy error if there are multiple files in the copy list that would end up with the same names when so-mangled.
Only the "extension" after the dot is affected -- the part preceding the dot is preserved.
If the filenames do not contain any dots/extensions, their names remain intact when copied.
This appears to be directly related to the old "filename.prg" naming method once demanded by some emulators.
To Reproduce
- by any means you see fit, create two files on a USB thumbdrive: "foo.bar1234" and "foo.bar5678"
- plug in a second storage device, say an SD card or maybe just another thumbdrive
- use the file browser to attempt to copy both files from one to the other
Result:
The first file that gets copied to the destination drive will end up named "foo.bar" without any of the trailing digits, both in the file browser and in the C64 context. The second file will just generate an error when copied.
On the other hand, if you add ".prg" extensions to the ends of those file names, making them "foo.bar1234.prg" and "foo.bar5678.prg", then those files copy over just fine, and the extra ".prg" extension is hidden from the C64's context, as one might expect.
Expected behavior
Filenames should be carried over to the destination drive exactly as the appear on the source drive, regardless of the filename's contents (unless the destination drive imposes some restriction).
I get that some C64 programs may require their files to appear as PRG filetype in the $ directory, and hence needing the ".prg" extension, but this isn't universal, and enforcing that naming method in the file copier is really not a good idea, especially if the user will be frequently working with files that defy this convention.
Applies to:
- Hardware type: C64 Ultimate, maybe also Ultimate64 and/or 1541U
- Firmware Version: 3.14 as supplied on the machine
- Git Hash: b169667
(note: you have a typo in your issue template, it has "Gash" when you meant to write "Hash")
Describe the bug
When using the C64 Ultimate's built-in file browser to copy some files from one storage medium to another (for example going from USB0 to SD), if a filename contains a dot, the portion after the dot gets truncated to three characters as if it's a traditional filename extension, which results in a file copy error if there are multiple files in the copy list that would end up with the same names when so-mangled.
Only the "extension" after the dot is affected -- the part preceding the dot is preserved.
If the filenames do not contain any dots/extensions, their names remain intact when copied.
This appears to be directly related to the old "filename.prg" naming method once demanded by some emulators.
To Reproduce
Result:
The first file that gets copied to the destination drive will end up named "foo.bar" without any of the trailing digits, both in the file browser and in the C64 context. The second file will just generate an error when copied.
On the other hand, if you add ".prg" extensions to the ends of those file names, making them "foo.bar1234.prg" and "foo.bar5678.prg", then those files copy over just fine, and the extra ".prg" extension is hidden from the C64's context, as one might expect.
Expected behavior
Filenames should be carried over to the destination drive exactly as the appear on the source drive, regardless of the filename's contents (unless the destination drive imposes some restriction).
I get that some C64 programs may require their files to appear as
PRGfiletype in the$directory, and hence needing the ".prg" extension, but this isn't universal, and enforcing that naming method in the file copier is really not a good idea, especially if the user will be frequently working with files that defy this convention.Applies to:
(note: you have a typo in your issue template, it has "Gash" when you meant to write "Hash")