{"action":"created","issue":{"url":"https://api.github.com/repos/mach-kernel/cadius/issues/7","repository_url":"https://api.github.com/repos/mach-kernel/cadius","labels_url":"https://api.github.com/repos/mach-kernel/cadius/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/mach-kernel/cadius/issues/7/comments","events_url":"https://api.github.com/repos/mach-kernel/cadius/issues/7/events","html_url":"https://github.com/mach-kernel/cadius/issues/7","id":296360510,"number":7,"title":"Meta Data Handling","user":{"login":"oliverschmidt","id":2664009,"avatar_url":"https://avatars0.githubusercontent.com/u/2664009?v=4","gravatar_id":"","url":"https://api.github.com/users/oliverschmidt","html_url":"https://github.com/oliverschmidt","followers_url":"https://api.github.com/users/oliverschmidt/followers","following_url":"https://api.github.com/users/oliverschmidt/following{/other_user}","gists_url":"https://api.github.com/users/oliverschmidt/gists{/gist_id}","starred_url":"https://api.github.com/users/oliverschmidt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oliverschmidt/subscriptions","organizations_url":"https://api.github.com/users/oliverschmidt/orgs","repos_url":"https://api.github.com/users/oliverschmidt/repos","events_url":"https://api.github.com/users/oliverschmidt/events{/privacy}","received_events_url":"https://api.github.com/users/oliverschmidt/received_events","type":"User","site_admin":false},"labels":[{"id":789322387,"url":"https://api.github.com/repos/mach-kernel/cadius/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2018-02-12T12:36:03Z","updated_at":"2018-02-13T21:57:17Z","closed_at":null,"author_association":"NONE","body":"Hi,\r\n\r\nI've pointing out the below several times in the past so in case it bothers you please just close this issue but I thought I'd give it another try here...\r\n\r\nThere are from my POV several options on how to transport meta data from a cross dev tool that produces Apple II files in some foreign filesystem (like Merlin32) to a tool that incorporates the files into a ProDOS / GS/OS filesystem (like Cadius):\r\n\r\n1. Sidecar file (like _FileInformation.txt):\r\nThe lifecycle of the file doesn't match the lifecycle of the main file. It gets forgotten when copying/moving the main file. It doesn't get deleted when the main file is deleted.\r\n\r\n2. Filename extension:\r\nThe name of the file changes when e.g. the load address of a plain BIN file is changed in its source code.\r\n\r\n   2.1 Either the extended filename is part of the Makefile, then the Makefile needs to be adjusted. Given that the Cadius-like tool is most likely called from within Makefiles this means that there is no real gain over command line arguments for providing the meta data in the first place.\r\n\r\n   2.2 Or the extended filename is not part of the Makefile but replaced with some $(wildcard) \"hack\". Then it gets pretty ugly when the Makefile is supposed to know the time stamp of that file to construct the right order of re-build commands.\r\n\r\n3. Proprietary foreign filesystem features:\r\nMacOS HFS+, Windows Alternate Datastreams, Linux XATTR etc. for sure allow to transport the meta data from the dev tool to the Cadius-like tool - if and only if they both run on the same filesystem. But as soon as it comes to sending a file to someone else, moving it to another filesystem, uploading it to some cloud space, putting it into an archive, <...> the meta data is lost.\r\n\r\n4. Proprietary file header:\r\nThe dev tools and the Cadius-like tools should agree on a common format to allow for interoperability.\r\n\r\nFrom my POV the last option is in fact the only really viable option!\r\n\r\n- The http://cc65.github.io/cc65/ toolchain uses a 4-byte DOS3.3 header. That header is supported by https://applecommander.github.io/ and https://bitbucket.org/magli143/exomizer/wiki/Home.\r\n\r\n- You have direct control/influence on Merlin32 and Cadius.\r\n\r\nSo I'd say if we agree on some proprietary file header and ...\r\n\r\n- You implement it both in Merlin32 and Cadius\r\n\r\n- I implement it in cc65\r\n\r\n- I talk to the AppleCommander and Exomizer authors to have it implemented\r\n\r\n... then we have for sure the momentum to create a standard and have this issue solved once for all!\r\n\r\nJust my two cents,\r\nOliver"},"comment":{"url":"https://api.github.com/repos/mach-kernel/cadius/issues/comments/365418456","html_url":"https://github.com/mach-kernel/cadius/issues/7#issuecomment-365418456","issue_url":"https://api.github.com/repos/mach-kernel/cadius/issues/7","id":365418456,"user":{"login":"oliverschmidt","id":2664009,"avatar_url":"https://avatars0.githubusercontent.com/u/2664009?v=4","gravatar_id":"","url":"https://api.github.com/users/oliverschmidt","html_url":"https://github.com/oliverschmidt","followers_url":"https://api.github.com/users/oliverschmidt/followers","following_url":"https://api.github.com/users/oliverschmidt/following{/other_user}","gists_url":"https://api.github.com/users/oliverschmidt/gists{/gist_id}","starred_url":"https://api.github.com/users/oliverschmidt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oliverschmidt/subscriptions","organizations_url":"https://api.github.com/users/oliverschmidt/orgs","repos_url":"https://api.github.com/users/oliverschmidt/repos","events_url":"https://api.github.com/users/oliverschmidt/events{/privacy}","received_events_url":"https://api.github.com/users/oliverschmidt/received_events","type":"User","site_admin":false},"created_at":"2018-02-13T21:57:16Z","updated_at":"2018-02-13T21:57:16Z","author_association":"NONE","body":"At the time I wrote https://github.com/mach-kernel/cadius/issues/7#issuecomment-364977675 I didn't know of AppleSingle.\r\n\r\nWhen I learned about AppleSingle I wondered: Is this just some old spec we can re-use instead of re-inventing the wheel or are there actual synergy effects with existing software supporting AppleSingle. Several packages were linked to far in this thread but there was no free package so far that would allow to do something with an AppleSingle file on a non-MacOS machine :-(\r\n\r\nBeside the - at least according to my current knowledge - missing synergy effect on Linux/Windows that means that it's hard to do interoperability tests without a MacOS machine. But maybe John is willing/able to help here when we send him AppleSingle files to check.\r\n\r\nApart from all that I see a issue with AppleSingle when compared to https://github.com/mach-kernel/cadius/issues/7#issuecomment-364977675. It contains more than it needs / more than it should for our use case - and those things don't seem to be really optional.\r\n\r\nBoth the PDF I linked and the source file linked say `Entry IDs 1, 3, and 8 are typically created for all files.` Those IDs are:\r\n- 1: Data Fork\r\n- 3: Real Name\r\n- 8: File Dates Info\r\n\r\n`Data Fork` is obvious but `Real Name` is an issue. Both from the implementer perspective and the user perspective: A modern tool chain likely consists of an assembler and a linker. The header is rather created by the assembler but the output filename is rather known to the linker. So there's no clean way to put the name of the actual AppleSingle file into the 'Real Name'. And even if there would be a good way to do it the AppleSingle filename might not conform to ProDOS name restrictions (like the 15 char length). So the assembler/linker would need to contain logic to shorten the AppleSingle filename for the `Real Name`. But I __really__ don't see such logic in those tools. Such logic belongs only to tools like Cadius. So the better alternative would be that the user needs to specify the `Real Name` \"somehow\" to the assembler (e.g. as part of the source file). But that may require an extension of the assembler and that may not be what the user expects. Additionally I think that the user has the right to expect that when he renames the AppleSingle file before giving it to Cadius that then the ProDOS file is renamed too.\r\n\r\n`File Dates Info` is to some extend a similar issue. What values should be written by the assembler? Why are they different to the ones of the AppleSingle file? Why should they ever be different? The PDF says `When initially created, a file’s backup time and any unknown entries are set to $80000000 or 0x80000000, the earliest reasonable time.` but the best case is that the resulting ProDOS file shows up as `<NO DATE>` which is a pitty given that the AppleSingle file has nice date values.\r\n\r\nSo what does that mean from my POV? I don't see me generating AppleSingle files with Entry ID's 3 and 8. I see for our use case AppleSingle files with those IDs:\r\n- 1: Data Fork (obligatory)\r\n- 11: ProDOS File Info (obligatory)\r\n- 2: Resource Fork (optional)\r\n\r\nhttps://tools.ietf.org/html/rfc1740 says `Each entry is optional and may or may not appear in the file.` so the files as I see them are in general valid AppleSingle files. However, if the existing tools presume ID 3 and 8 to be present then the compatibility we were after doesn't exist. The conclusion could be to rather go for something like https://github.com/mach-kernel/cadius/issues/7#issuecomment-364977675 in the first place.\r\n\r\nOpinions?"}}
{"actor":{"display_login":"oliverschmidt"}}