Issue with with 0 length data fork files

[lebraseric]

Hi,

I came across this issue while dealing with extended storage type files with 0 length data fork. These files actually exist on GS/OS system disks e.g the file System/System.Setup/Sys.Resources.
Having encapsulated this file in an AppleSingle file, this is what I obtain with asu (the original file is on SYSTEM 5.0.4 disk):

$ asu.sh info Sys.Resources 
Real Name: Sys.Resources
ProDOS info:
  Access: 0xE3
  File Type: 0xF9
  Auxtype: 0x0000
File dates info:
  Creation: 1989-06-14T08:04:00Z
  Modification: 1989-06-14T08:04:00Z
  Access: 1931-12-13T20:45:52Z
  Backup: 1931-12-13T20:45:52Z
Data Fork: Present, 0 bytes
Resource Fork: Present, 8 207 bytes
$ asu.sh analyze Sys.Resources 
0000: 00 05 16 00 .. .. .. .. .. .. .. .. .. .. .. .. | ....             | Magic number
0004: 00 02 00 00 .. .. .. .. .. .. .. .. .. .. .. .. | ....             | Version
0008: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | Filler
0018: 00 05 .. .. .. .. .. .. .. .. .. .. .. .. .. .. | ..               | Number of entries
001a: 00 00 00 03 00 00 02 00 00 00 00 0d .. .. .. .. | ............     | Entry header
0200: 53 79 73 2e 52 65 73 6f 75 72 63 65 73 .. .. .. | Sys.Resources    | Real Name
0026: 00 00 00 08 00 00 04 00 00 00 00 10 .. .. .. .. | ............     | Entry header
0400: ec 28 cd f0 ec 28 cd f0 80 00 00 00 80 00 00 00 | .(...(.......... | File Dates Info
0032: 00 00 00 0b 00 00 06 00 00 00 00 08 .. .. .. .. | ............     | Entry header
0600: 00 e3 00 f9 00 00 00 00 .. .. .. .. .. .. .. .. | ........         | ProDOS File Info
003e: 00 00 00 01 00 00 08 00 00 00 00 00 .. .. .. .. | ............     | Entry header
Error: low and high cannot be the same
$ asu.sh extract Sys.Resources 
Error: There is no data in the data fork, aborting
$

Either the AppleSingle is malformed, either detected errors are inappropriate.

The AppleSingle encapsulation has been produced by a tool I am developing, to restore a GS/OS drive from a Salvation Bakkup disk set.

If I can participate in testing or improving the code in any way, I would gladly help with the project.

Thank you in advance for your attention, Eric

[a2geek]

I looked at this a little and can only recreate the "there is no data in the data fork" message. Would you be willing to attach your Sys.Resources AppleSingle file? Trying to identify what is causing the "low and high cannot be the same" message. Thanks!

[lebraseric]

Sys.Resources.gz

Here it is.

[a2geek]

(Forgot to tag commits: ea58bc8 and 0651919).

[a2geek]

Relaxed the edit and added a little bit of support for the empty entries as seen via analyze). I did bump this to Java 11 since the rest of AppleCommander is heading there, as a note.

Relevant portion of output:

003e: 00 00 00 01 00 00 08 00 00 00 00 00 .. .. .. .. | ............     | Entry header
0800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. |                  | Data Fork (empty)
004a: 00 00 00 02 00 00 0a 00 00 00 20 0f .. .. .. .. | .......... .     | Entry header
0a00: 00 00 00 00 8c 00 00 00 32 08 00 00 00 00 00 00 | ........2....... | Resource Fork

[a2geek]

Here's a copy of the pre-release. If you can verify this piece works, that would be great!
(Sorry for the Zip, but I can't attach a Jar file. Just unzip it...)

applesingle-tools-asu-1.2.2-SNAPSHOT.zip

[lebraseric]

I've done some testing with this pre-release and it seems to work very well. Files I have tested include the content of SYSTEM/CDEVS directory (the Control Panel NDA resource files).
These files included with the Apple IIGS System 5.0 and successors are interesting because they all contain a data fork + a resource fork, and the data fork is empty for all of them but one, the exception being the file CDEV.DATA which has a non empty data fork + a zero length resource fork (only of this kind I've seen so far).
I have encoded all these files to AppleSingle and passed them through asu analyze. The information displayed is OK for every file I have tested.
So I would say that the analyzeoption is now working the expected way.

[a2geek]

Sorry for the delay. That's great! Essentially, it was an edit that didn't belong.
(Edit: I'm going to let the new release sit for a bit. Just in case something is discovered while acx is worked on. I don't expect anything, but you never know!)

[a2geek]

Finally preparing a release! Glad I gave you a snapshot last year. lol

[lebraseric]

Thanks for fixing the issue 👍 (I succeeded in restoring my backup in the meantime, thanks to the snapshot you provided me !)