mirror of
https://github.com/ksherlock/profuse.git
synced 2024-11-26 05:49:21 +00:00
import google code wiki
parent
68d63b00a5
commit
1a1673f17e
6
ChangeLog.md
Normal file
6
ChangeLog.md
Normal file
@ -0,0 +1,6 @@
|
||||
R4 (on Google Code)
|
||||
|
||||
* Create `com.apple.FinderInfo` xattr for all files
|
||||
* Populate `com.apple.FinderInfo` creator/filetype info similar to system 6 if not populated.
|
||||
* Fix for DST bug
|
||||
* add `user.mime_type` and `user.mimecharset`xattr for linux.
|
44
DirectoryHeader.md
Normal file
44
DirectoryHeader.md
Normal file
@ -0,0 +1,44 @@
|
||||
This is the directory header, as originally defined in ProDOS/SOS.
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 4 bits (high) |
|
||||
| name\_length | $00 | 4 bits (low) |
|
||||
| file\_name | $01 | 15 bytes |
|
||||
| reserved | $10 | 8 bytes |
|
||||
| creation | $18 | 4 bytes |
|
||||
| version | $1c | 1 byte |
|
||||
| min\_version | $1d | 1 byte |
|
||||
| access | $1e | 1 byte |
|
||||
| entry\_length | $1f | 1 byte |
|
||||
| entries\_per\_block | $20 | 1 byte |
|
||||
| file\_count | $21 | 2 byte |
|
||||
| parent\_pointer | $23 | 2 bytes |
|
||||
| parent\_entry\_number | $25 | 1 byte |
|
||||
| parent\_entry\_length | $26 | 1 byte |
|
||||
|
||||
|
||||
# Updates
|
||||
|
||||
* SOS 1.3 and ProDOS 1.7 source code refer to the reserved data as the password enabled byte/password. Neither actually implemented password support, though.
|
||||
* SOS 1.3 stores $76 in the password\_enabled byte.
|
||||
* ProDOS 1.7 stores $75 in the password\_enabled byte. When reading a directory, the password\_enabled byte MUST have 5 bits set (eg $75 or $76). Otherwise, error $4a is returned.
|
||||
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 4 bits (high) |
|
||||
| name\_length | $00 | 4 bits (low) |
|
||||
| file\_name | $01 | 15 bytes |
|
||||
| password\_enabled | $10 | 1 byte |
|
||||
| encoded\_password | $11 | 7 bytes |
|
||||
| creation | $18 | 4 bytes |
|
||||
| version | $1c | 1 byte |
|
||||
| min\_version | $1d | 1 byte |
|
||||
| access | $1e | 1 byte |
|
||||
| entry\_length | $1f | 1 byte |
|
||||
| entries\_per\_block | $20 | 1 byte |
|
||||
| file\_count | $21 | 2 byte |
|
||||
| parent\_pointer | $23 | 2 bytes |
|
||||
| parent\_entry\_number | $25 | 1 byte |
|
||||
| parent\_entry\_length | $26 | 1 byte |
|
33
DiskCopy42.md
Normal file
33
DiskCopy42.md
Normal file
@ -0,0 +1,33 @@
|
||||
http://www.nulib.com/library/FTN.e00005.htm
|
||||
|
||||
I recently encountered a 32-meg image with the following values:
|
||||
|
||||
| **offset** | **description** | **value** |
|
||||
|:-----------|:----------------|:----------|
|
||||
| +80 | disk format | $ff |
|
||||
| +81 | format byte | $22 |
|
||||
|
||||
## checksum algorithm (c)
|
||||
|
||||
```
|
||||
|
||||
/*
|
||||
* length must be even.
|
||||
*/
|
||||
uint32_t checksum(uint8_t *data, size_t length)
|
||||
{
|
||||
size_t i;
|
||||
uint32_t rv = 0;
|
||||
|
||||
for (i = 0; i < length; i += 2)
|
||||
{
|
||||
rv += data[i] << 8;
|
||||
rv += data[i+1];
|
||||
|
||||
rv = (rv >> 1) + (rv << 31);
|
||||
}
|
||||
|
||||
return rv;
|
||||
}
|
||||
|
||||
```
|
13
ExtendedAttributes.md
Normal file
13
ExtendedAttributes.md
Normal file
@ -0,0 +1,13 @@
|
||||
# Introduction
|
||||
|
||||
ProFUSE maps certain ProDOS metadata to extended attributes, which applications can access.
|
||||
|
||||
# Details
|
||||
|
||||
| Attribute | Size |Type of file | Description |
|
||||
|:----------|:-----|:------------|:------------|
|
||||
| prodos.FileType |1 byte | All files (excluding directories) | The ProDOS file type byte |
|
||||
| prodos.AuxType | 2 bytes | All files (excluding directories) | The ProDOS aux type word, in little endian format |
|
||||
| prodos.ResourceFork | variable | Extended files | The raw resource fork data |
|
||||
| com.apple.FinderInfo | 32 bytes | Extended files | Macintosh Finder info |
|
||||
| com.apple.TextEncoding | variable | Teach Text files | Indicates MacRoman encoding |
|
40
ExtendedFile.md
Normal file
40
ExtendedFile.md
Normal file
@ -0,0 +1,40 @@
|
||||
# Introduction
|
||||
|
||||
Extended files are used for storing files which contain a resource fork. They are not supported by ProDOS 8.
|
||||
|
||||
|
||||
| storage\_type | $05 |
|
||||
|:--------------|:----|
|
||||
|
||||
The `key_pointer` is a block containing 2 mini entries; one for the data fork (at offset $0), one for the resource fork (at offset $100).
|
||||
|
||||
|
||||
## Mini Entry
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 1 byte |
|
||||
| key\_block | $01 | 2 bytes |
|
||||
| blocks\_used | $03 | 2 bytes |
|
||||
| eof | $05 | 2 bytes |
|
||||
|
||||
Unlike the [File Entry](FileEntry.md) `storage_type` field, the high nibble is 0. The only valid values are $01, $02, or $03.
|
||||
|
||||
As of System 6.0, Macintosh finder information can be stored after the data fork mini entry (starting offset of $08).
|
||||
|
||||
| **Name** | **Offset** | **Size** | **Value** |
|
||||
|:---------|:-----------|:---------|:----------|
|
||||
| size\_1 | $00 | 1 byte | 18 |
|
||||
| type\_1 | $01 | 1 byte | 1 |
|
||||
| FInfo | $02 | 16 bytes | ... |
|
||||
| size\_2 | $12 | 1 byte | 18 |
|
||||
| type\_2 | $13 | 1 byte | 2 |
|
||||
| xFInfo | $14 | 16 bytes | ... |
|
||||
| end\_mark | $24 | 1 byte | 0 |
|
||||
|
||||
One or both of FInfo and xFInfo may be missing, in which case they should be considered 0-filled.
|
||||
|
||||
# References
|
||||
|
||||
* [ProDOS Technote #25](http://www.umich.edu/~archive/apple2/technotes/tn/pdos/TN.PDOS.025)
|
||||
* Programmer's Reference for 6.0 (pages 324, 325)
|
58
FileEntry.md
Normal file
58
FileEntry.md
Normal file
@ -0,0 +1,58 @@
|
||||
This is the file entry, as originally defined in ProDOS/SOS.
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 4 bits (high) |
|
||||
| name\_length | $00 | 4 bits (low) |
|
||||
| file\_name | $01 | 15 bytes |
|
||||
| file\_type | $10 | 1 byte |
|
||||
| key\_pointer | $11 | 2 bytes |
|
||||
| blocks\_used | $13 | 2 bytes |
|
||||
| EOF | $15 | 3 bytes |
|
||||
| creation | $18 | 4 bytes |
|
||||
| version | $1c | 1 byte |
|
||||
| min\_version | $1d | 1 byte |
|
||||
| access | $1e | 1 byte |
|
||||
| aux\_type | $1f | 2 bytes |
|
||||
| last\_mod | $21 | 4 bytes |
|
||||
| header\_pointer | $25 | 2 bytes |
|
||||
|
||||
# Updates
|
||||
|
||||
* The `version`/`min_version` fields were deprecated and replaced with filename case information as of IIgs System 5. Refer to [GS/OS Technote #8](http://www.umich.edu/~archive/apple2/technotes/tn/gsos/TN.GSOS.008)
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 4 bits (high) |
|
||||
| name\_length | $00 | 4 bits (low) |
|
||||
| file\_name | $01 | 15 bytes |
|
||||
| file\_type | $10 | 1 byte |
|
||||
| key\_pointer | $11 | 2 bytes |
|
||||
| blocks\_used | $13 | 2 bytes |
|
||||
| EOF | $15 | 3 bytes |
|
||||
| creation | $18 | 4 bytes |
|
||||
| file\_name\_case\_bits | $1c | 2 bytes |
|
||||
| access | $1e | 1 byte |
|
||||
| aux\_type | $1f | 2 bytes |
|
||||
| last\_mod | $21 | 4 bytes |
|
||||
| header\_pointer | $25 | 2 bytes |
|
||||
|
||||
# Fields
|
||||
|
||||
## storage\_type
|
||||
|
||||
The storage type is stored in the high 4 bits. Valid values are:
|
||||
|
||||
| $01 | [Seedling File](SeedlingFile.md) |
|
||||
|:----|:---------------------------------|
|
||||
| $02 | [Sapling File](SaplingFile.md) |
|
||||
| $03 | [Tree File](TreeFile.md) |
|
||||
| $04 | [Apple II Pascal Area](PascalArea.md) |
|
||||
| $05 | [Extended File](ExtendedFile.md) |
|
||||
| $0D | [Directory](DirectoryFile.md) |
|
||||
| $0E | Subdirectory Key Block |
|
||||
| $0F | Volume Key Block |
|
||||
|
||||
Type 0x04 and 0x05 were not a part of the original ProDOS specification and are not supported under ProDOS 8. Refer to [ProDOS Technote #25](http://www.umich.edu/~archive/apple2/technotes/tn/pdos/TN.PDOS.025)
|
||||
|
||||
Types 0x0E and 0x0F are not used in the File Entry.
|
25
FreeBSDSupport.md
Normal file
25
FreeBSDSupport.md
Normal file
@ -0,0 +1,25 @@
|
||||
# Introduction
|
||||
|
||||
ProFUSE has been tested with FreeBSD version 7.1, [fuse4bsd](http://fuse4bsd.creo.hu/), 0.3.9, and FUSE 2.7.3
|
||||
|
||||
# Compiling
|
||||
|
||||
The fusefs-kmod and fusefs-libs packages must be installed.
|
||||
|
||||
```
|
||||
make -f makefile.freebsd
|
||||
```
|
||||
|
||||
# Usage
|
||||
|
||||
```
|
||||
|
||||
profuse [options] disk-image mount-folder
|
||||
|
||||
```
|
||||
|
||||
# Limitations
|
||||
|
||||
See the [fuse4bsd](http://fuse4bsd.creo.hu/) site for more details on the FreeBSD FUSE module.
|
||||
|
||||
Fuse For FreeBSD does not currently support extended attributes, so they will not be accessible.
|
28
LinuxSupport.md
Normal file
28
LinuxSupport.md
Normal file
@ -0,0 +1,28 @@
|
||||
# Introduction
|
||||
|
||||
ProFUSE has been tested with Linux 2.6.x/ARM with gcc 4.x and fuse 2.7.4. For lenny, that means `apt-get install libfuse2 libfuse-dev`. Etch uses fuse 2.5.3, which is not supported. You will need to compile and install your own libfuse.
|
||||
|
||||
|
||||
# Compiling
|
||||
|
||||
FUSE 2.6+ must be installed.
|
||||
|
||||
```
|
||||
make -f makefile.linux
|
||||
```
|
||||
|
||||
# Usage
|
||||
|
||||
```
|
||||
profuse [options] disk-image mount-folder
|
||||
```
|
||||
|
||||
# Limitations
|
||||
|
||||
The `profuse` command must be run by root (or be setguid root). By default, the mount dir can only be accessed by the user that mounted it. If it wasn't you, it will show up as:
|
||||
|
||||
```
|
||||
?--------- ? ? ? ? ? mnt
|
||||
```
|
||||
|
||||
and will be inaccessible. The `-oallow_other` flag will give everyone access the mount dir.
|
31
MountOptions.md
Normal file
31
MountOptions.md
Normal file
@ -0,0 +1,31 @@
|
||||
This is a list of common (and useful) mounting options for ProFUSE. Some are ProFUSE specific, some are handled by FUSE or MacFUSE (see their documentation for a full list).
|
||||
|
||||
Example:
|
||||
|
||||
`profuse -odebug disk.raw /mnt/`
|
||||
|
||||
|
||||
|
||||
# ProFUSE specific
|
||||
|
||||
`--dos-order`
|
||||
|
||||
While most ProDOS disk images are in ProDOS order, some people occasionally create them in dos 3.3 order (usually 5.25" disk images with a `.do` or `.dsk` extension). the `--dos-order` flag will compensate for their screwed up interleaving.
|
||||
|
||||
|
||||
# FUSE/MacFUSE specific
|
||||
|
||||
|
||||
`-odebug`
|
||||
|
||||
Print debugging information for every FUSE call made.
|
||||
|
||||
`-oallow_others`
|
||||
|
||||
Allow anyone to access the mounted disk image. Normally, only the user who mounted it has access.
|
||||
|
||||
# MacFUSE specifix
|
||||
|
||||
`-olocal`
|
||||
|
||||
Mount the disk image as a local disk, which will show up on the desktop (and may have other implications)
|
31
NibbleEncoding.md
Normal file
31
NibbleEncoding.md
Normal file
@ -0,0 +1,31 @@
|
||||
(Taken from Beneath Apple ProDOS)
|
||||
|
||||
# Address Fields
|
||||
|
||||
An examination of the contents of the two types of fields is on order. The Address Field contains the address or identifying information about the Data Field which follows it. The volume, track, and sector number of any given sector can be thought of as its ``address,'' much like a country, city, and street number might identify a house. As shown previously in Figure 3.6, there are a number of components which make up the Address Field. A more detailed illustration is given in Figure 3.12.
|
||||
|
||||
|
||||
| Prologue | Volume | Track | Sector | Checksum | Epilogue |
|
||||
|:---------|:-------|:------|:-------|:---------|:---------|
|
||||
| `D5 AA 96` | `XX YY` | `XX YY` | `XX YY` | `XX YY` | `DE AA EB` |
|
||||
|
||||
Figure 3.12 Address Field
|
||||
|
||||
Each byte of the Address Field is encoded into two bytes when written to the disk. APPENDIX C describes the ``4 and 4'' method used for Address Field encoding.
|
||||
|
||||
|
||||
The prologue consists of three bytes which form a unique sequence, found in no other component of the track. This fact enables ProDOS to locate and Address Field with almost no possibility of error. The three bytes are $D5, $AA, and $96. The $D5 and $AA are reserved (never written as data), this insuring the uniqueness of the prologue. The $96, following this unique string, indicates that the data following constitutes an Address Field (as opposed to a Data Field). The address information follows next, consisting of the volume`*`, track, and sector number and a checksum. This information is absolutely essential for ProDOS to know where it is positioned on a particular diskette. The checksum is computed by exclusive-ORing the first three pieces of information, and is used to verify it's integrity. Lastly follows the epilogue, which contains the three bytes $DE, $AA, and $EB. The $EB is only partly written during initialization, and is therefore never verified when an Address Field is read. The epilogue bytes are sometimes referred to as bit-slip marks, which provide added assurance that the drive is still in sync with the bytes on the disk. These bytes are probably unnecessary, but do provide a means of double checking.
|
||||
|
||||
`*` Volume number is a leftover from earlier operating systems and is not used by ProDOS.
|
||||
|
||||
# Data Fields
|
||||
|
||||
The other field type is the Data Field. Much like the Address Field, it consists of a prologue, data, checksum, and an epilogue (refer to Figure 3.13). The prologue differs only in the third byte. The bytes are $D5, $AA, and $AD, which again form a unique sequence, enabling ProDOS to locate the beginning of the sector data. The data consists of 342 bytes of encoded data. (The encoding scheme used is quite complex and is documented in detail in APPENDIX C.) The data is followed by a checksum byte, used to verify the integrity of the data just read. The epilogue portion of the Data Field is absolutely identical to the epilogue in the Address Field and serves the same function.
|
||||
|
||||
| Prologue | User Data | Dhecksum | Epilogue |
|
||||
|:---------|:----------|:---------|:---------|
|
||||
| `D5 AA AD` | 342 bytes data (six and two encoded) | `XX` | `DE AA EB`|
|
||||
|
||||
Figure 3.13 Data Field
|
||||
|
||||
|
1
OSX104Support.md
Normal file
1
OSX104Support.md
Normal file
@ -0,0 +1 @@
|
||||
OS X 10.4 uses a 32-bit kernel interface and does not have 64-bit ino\_t support. Consequently, there is no libfuse\_ino64 and libfuse is only compiled for 32-bit ppc and 32-bit x86.
|
17
OSXUsage.md
Normal file
17
OSXUsage.md
Normal file
@ -0,0 +1,17 @@
|
||||
# Introduction
|
||||
|
||||
The OS X version of ProFUSE (and MacFUSE) has a few enhancements and pitfalls.
|
||||
|
||||
# Details
|
||||
|
||||
The profuse command needs to be run from the commandline (aka Terminal).
|
||||
|
||||
```
|
||||
profuse name_of_disk_image
|
||||
```
|
||||
|
||||
|
||||
* you can drag a file onto the terminal window if you don't want to type out the full pathname.
|
||||
* Unlike the linux/unix version, a mountpoint is not necessary (one will be created in the /Volumes/ folder for you).
|
||||
* In finder, choose Go->Computer (Shift-Command-C) to view mounted disks. Your ProDOS disk image should appear there.
|
||||
* By default, only local disks appear on the Finder desktop. To make ProDOS disk images show up on the Finder desktop, check "Connected servers" in the Finder preferences panel.
|
15
PascalArea.md
Normal file
15
PascalArea.md
Normal file
@ -0,0 +1,15 @@
|
||||
# Introduction
|
||||
|
||||
An Apple II Pascal Area is a collection of psuedo-volumes (disk images) for use with the Pascal Profile Manager.
|
||||
|
||||
| storage\_type | $04 |
|
||||
|:--------------|:----|
|
||||
| file\_name | PASCAL.AREA |
|
||||
| file\_type | $EF |
|
||||
|
||||
|
||||
`key_pointer` is first block of the file. The file extends to the end of the disk as a contiguous file. Therefore, only one Pascal Area may exist per ProDOS volume.
|
||||
|
||||
References
|
||||
|
||||
* [ProDOS Technote #25](http://www.umich.edu/~archive/apple2/technotes/tn/pdos/TN.PDOS.025)
|
164
PascalFileSystem.md
Normal file
164
PascalFileSystem.md
Normal file
@ -0,0 +1,164 @@
|
||||
# Introduction
|
||||
|
||||
UCSD Pascal was a language/virtual machine/OS/File System developed by the University of California, San Diego. Apple sold an Apple II implementation/port. IIgs System 6 included a read-only Apple Pascal FST.
|
||||
|
||||
The Pascal File system used 512k blocks (like ProDOS) and 2-byte block pointers (which implies a maximum disk size of 32 Meg, like ProDOS). Files don't store their file size per se, but rather the start block, end block, and size of last block. This implies a maximum file size of 32 Meg, minus the overhead of boot and volume blocks.
|
||||
|
||||
|
||||
Block 0 and 1 contain boot code. Blocks 2--5 contain the volume header and up to 77 file entries. When a file is deleted, all subsequent records are moved up.
|
||||
|
||||
# Volume Header
|
||||
|
||||
All values are little-endian unless specified otherwise. All blocks are 512 bytes in length.
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| first\_block | $00 | 2 bytes |
|
||||
| last\_block | $02 | 2 bytes |
|
||||
| file\_kind | $04 | 1 byte |
|
||||
| reserved | $05 | 1 byte |
|
||||
| volume\_name | $06 | 8 bytes |
|
||||
| volume\_last\_block | $0e | 2 bytes |
|
||||
| file\_count | $10 | 2 byte |
|
||||
| load\_time | $12 | 2 bytes |
|
||||
| boot\_date | $14 | 2 bytes |
|
||||
| reserved | $16 | 4 bytes |
|
||||
|
||||
## fields
|
||||
### first\_block
|
||||
|
||||
The first block of the file system header (boot block and directory blocks) This should always be 0.
|
||||
|
||||
### last\_block
|
||||
|
||||
The block _after_ the last block of the directory structure. (i.e., the next available block). This should always be 6.
|
||||
|
||||
### file\_kind
|
||||
|
||||
This should always be 0.
|
||||
|
||||
### volume\_name
|
||||
|
||||
The volume name, stored with a leading length byte (i.e., a pstring). May be 1--7 characters in length.
|
||||
|
||||
|
||||
### volume\_last\_block
|
||||
The number of blocks on the volume.
|
||||
|
||||
### file count
|
||||
|
||||
The number of files. May be 0--77.
|
||||
|
||||
### load\_time
|
||||
|
||||
_????_
|
||||
|
||||
### boot\_date
|
||||
|
||||
The date last booted.
|
||||
|
||||
|
||||
# File Entry
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| first\_block | $00 | 2 bytes |
|
||||
| last\_block | $02 | 2 bytes |
|
||||
| file\_kind | $04 | 1 byte |
|
||||
| status | $05 | 1 byte |
|
||||
| file\_name | $06 | 16 bytes |
|
||||
| last\_byte | $16 | 2 bytes |
|
||||
| modification\_date | $18 | 2 bytes |
|
||||
|
||||
|
||||
## fields
|
||||
|
||||
### first\_block
|
||||
|
||||
The first block of the file
|
||||
|
||||
### last\_block
|
||||
|
||||
|
||||
The block _after_ the last file block (i.e., the next available block).
|
||||
|
||||
### file\_kind
|
||||
|
||||
| **Name** | **Value** | **Use** |
|
||||
|:---------|:----------|:--------|
|
||||
| untypedfile | $00 | Volume Header |
|
||||
| xdskfile | $01 | Bad blocks |
|
||||
| codefile | $02 | Machine executable code |
|
||||
| textfile | $03 | Text |
|
||||
| infofile | $04 | Debugger Information |
|
||||
| datafile | $05 | Data |
|
||||
| graffile | $06 | Compressed graphic image `*` |
|
||||
| fotofile | $07 | Screen image |
|
||||
| securedir | $08 | Subdirectory [???] `*` |
|
||||
|
||||
`*` Not implemented.
|
||||
|
||||
### status
|
||||
|
||||
Used by wildcard file listings [???]
|
||||
|
||||
N.B. -- bit 0 is the status bit, all other bits are reserved.
|
||||
|
||||
### file\_name
|
||||
|
||||
The file name, stored with a leading length byte (i.e., a pstring). May be 1--15 characters in length.
|
||||
|
||||
|
||||
### last\_byte
|
||||
|
||||
The number of bytes used in the last block. Should be 1--512.
|
||||
|
||||
### modification\_date
|
||||
|
||||
The date the file was created or last modified.
|
||||
|
||||
# Dates
|
||||
|
||||
Dates are stored in a 2 bytes structure:
|
||||
|
||||
| **Field** | **bits** | **range** |
|
||||
|:----------|:---------|:----------|
|
||||
| year | 15--9 | 0-100 |
|
||||
| day |8--4 | 0--31 |
|
||||
| month | 0--3 | 0 -- 12 |
|
||||
|
||||
|
||||
`yyyy yyyd dddd mmmm`
|
||||
|
||||
Year 100 is used to indicate a temporary file.
|
||||
|
||||
|
||||
# File Name Restrictions
|
||||
|
||||
There seems to be a lot of bad information about file name restrictions. [Wikipedia](http://en.wikipedia.org/wiki/Apple_Pascal) states:
|
||||
|
||||
_Apple Pascal dropped the length to fifteen characters and allowed only letters, numbers and periods to be used._
|
||||
|
||||
The [UCSD Pascal II manual](http://www.bitsavers.org/pdf/univOfCalSanDiego/UCSD_PASCAL_II.0_Manual_Mar79.pdf) states:
|
||||
|
||||
_A volume name be be 7 or less characters long and may not contain '=', '$', '?' or ','._
|
||||
|
||||
_A legal filename can consist of up to 15 characters. ... Lower-case letters are translated to upper-case, and blanks and non-printing characters are removed from the filename. Legal characters for filenames are the alphanumerics and the special characters '-', '/', '\', '_', and '.'.
|
||||
|
||||
Research (with the file manager) has shown that the only illegal characters are:
|
||||
|
||||
* $
|
||||
* =
|
||||
* ?
|
||||
* ,
|
||||
* whitespace (stripped out)
|
||||
|
||||
Additionally, the file manager cannot create (or transfer to) files with a '['. I did not try creating a '[' file programmatically, so its status is ambiguous.
|
||||
|
||||
For volume names, ':' and subsequent characters are stripped. The illegal filename characters are allowed but confuse the file manager. You can still refer to the disk by volume number though.
|
||||
|
||||
|
||||
# References
|
||||
|
||||
* http://groups.google.com/group/comp.sys.apple2.programmer/browse_thread/thread/85b993a1c8a0c504/5faf503ef4be5756?hl=en&ie=UTF-8
|
||||
* [Pascal Technote #16](http://www.umich.edu/~archive/apple2/technotes/tn/pasc/TN.PASC.016)
|
16
SaplingFile.md
Normal file
16
SaplingFile.md
Normal file
@ -0,0 +1,16 @@
|
||||
# Introduction
|
||||
|
||||
Sapling files have a 1-block index. There is no resource fork
|
||||
|
||||
| storage\_type | $02 |
|
||||
|:--------------|:----|
|
||||
| blocks\_used | 1--257 |
|
||||
| eof | 513--131072 |
|
||||
|
||||
The `key_pointer` field is a pointer of 256 blocks, each of which points to 512 bytes of data.
|
||||
|
||||
# Sparse Files
|
||||
|
||||
If any block in the index is 0, that block should be considered zero-filled.
|
||||
|
||||
# References
|
16
SeedlingFile.md
Normal file
16
SeedlingFile.md
Normal file
@ -0,0 +1,16 @@
|
||||
# Introduction
|
||||
|
||||
Seedling files have a data fork that can fit within 1 block (the `key_pointer`) and no resource fork.
|
||||
|
||||
| storage\_type | $01 |
|
||||
|:--------------|:----|
|
||||
| blocks\_used | 1 |
|
||||
| eof | 0-512|
|
||||
|
||||
|
||||
|
||||
# Sparse Files
|
||||
|
||||
Sparse seedling files may have an `eof` that exceed the 512 byte/1 block limit. Bytes 513--`eof` are considered zero-filled.
|
||||
|
||||
# References
|
84
UniversalDiskImageFormat.md
Normal file
84
UniversalDiskImageFormat.md
Normal file
@ -0,0 +1,84 @@
|
||||
Please refer to the [documentation](http://web.archive.org/web/20060308055210/http://www.a2central.com/programming/filetypes/ftne00130.html) for any ambiguities.
|
||||
|
||||
|
||||
Universal Disk Images (.2mg or .2img) consist of a 64-byte header followed by disk image data. An optional comment chunk and creator-specific chunk (in that order) may be present after the image data.
|
||||
|
||||
All values are stored in little endian format.
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| magic\_code | $00 | 4 bytes |
|
||||
| creator\_code | $04 | 4 bytes |
|
||||
| header\_length | $08 | 2 bytes |
|
||||
| version | $0a | 2 bytes |
|
||||
| format | $0c | 4 bytes |
|
||||
| flags | $10 | 4 bytes |
|
||||
| blocks | $14 | 4 bytes |
|
||||
| data\_offset | $18 | 4 bytes |
|
||||
| data\_length | $1c | 4 bytes |
|
||||
| comment\_offset | $20 | 4 bytes |
|
||||
| comment\_length | $24 | 4 bytes |
|
||||
| creator\_offset | $28 | 4 bytes |
|
||||
| creator\_length | $2c | 4 bytes |
|
||||
| reserved | $30 | 16 bytes |
|
||||
|
||||
|
||||
## magic\_code
|
||||
|
||||
This is the string '2IMG'.
|
||||
|
||||
## creator\_code
|
||||
This is a four-character tag which identifies the file creator. Currently know values are:
|
||||
|
||||
| **Application** | **Code** |
|
||||
|:----------------|:---------|
|
||||
| Bernie ][ the Rescue | B2TR |
|
||||
| Catakig | CTKG |
|
||||
| Sheppy's ImageMaker | ShIm |
|
||||
| Sweet 16 | WOOF |
|
||||
| ProFUSE | PRFS |
|
||||
|
||||
## header\_length
|
||||
This is the length of the header. Although the documentation specifies 52 (which excludes reserved bytes), some files are known to use 64.
|
||||
|
||||
## version
|
||||
The version number of the image file. This should be 1.
|
||||
|
||||
## image\_format
|
||||
The image data format. Valid values are:
|
||||
|
||||
| **Format** | **Value** |
|
||||
|:-----------|:----------|
|
||||
| DOS 3.3 Order | 0 |
|
||||
| ProDOS Order | 1 |
|
||||
| Nibblized data | 2 |
|
||||
|
||||
## flags
|
||||
Bit flags pertaining to the disk image. Undefined bits should be set to 0.
|
||||
|
||||
| **Bit** | **Description** |
|
||||
|:--------|:----------------|
|
||||
| 31 | If this bit is set, the disk is locked. |
|
||||
| 8 | If this bit is set, bits 0--7 are valid. If this bit is not set, a <br> volume number of 254 should be assumed <br>
|
||||
<tr><td> 0--7 </td><td> The DOS 3.3 volume number (0--254). Only valid if bit 8 is set </td></tr></tbody></table>
|
||||
|
||||
<h2>blocks
|
||||
The number of 512-byte blocks in the disk image. For Non-ProDOS Order disk images, this field should be 0.
|
||||
|
||||
## data\_offset
|
||||
Offset to the first byte of the image data. The image data must come before the comment data and the creator data (if present).
|
||||
|
||||
## data\_length
|
||||
Length of the image data in bytes. For ProDOS Order disk image, this should be blocks `*` 512.
|
||||
|
||||
## comment\_offset
|
||||
Offset to the first byte of the comment data. May be 0 if there is no comment.
|
||||
|
||||
## comment\_length
|
||||
Length of the comment data. May be 0 if there is no comment.
|
||||
|
||||
## creator\_offset
|
||||
Offset to the first byte of the creator-specific data. May be 0 if there is no creator-specific data.
|
||||
|
||||
## creator\_length
|
||||
Length of the creator-specific data. May be 0 if there is no creator-specific data.
|
41
VolumeHeader.md
Normal file
41
VolumeHeader.md
Normal file
@ -0,0 +1,41 @@
|
||||
This is the volume directory, as originally defined in ProDOS/SOS.
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 4 bits (high) |
|
||||
| name\_length | $00 | 4 bits (low) |
|
||||
| file\_name | $01 | 15 bytes |
|
||||
| reserved | $10 | 8 bytes |
|
||||
| creation | $18 | 4 bytes |
|
||||
| version | $1c | 1 byte |
|
||||
| min\_version | $1d | 1 byte |
|
||||
| access | $1e | 1 byte |
|
||||
| entry\_length | $1f | 1 byte |
|
||||
| entries\_per\_block | $20 | 1 byte |
|
||||
| file\_count | $21 | 2 byte |
|
||||
| bit\_map\_pointer | $23 | 2 bytes |
|
||||
| total\_blocks | $25 | 2 bytes |
|
||||
|
||||
# Updates
|
||||
|
||||
* Part of the reserved data is used to store the modification date. This is not documented but is reportedly specific to the GS/OS ProDOS FST.
|
||||
* Part of the reserved data is used to store `file_name` case information as of IIgs System 5. Refer to [GS/OS Technote #8](http://www.umich.edu/~archive/apple2/technotes/tn/gsos/TN.GSOS.008).
|
||||
|
||||
|
||||
| **Name** | **Offset** | **Size** |
|
||||
|:---------|:-----------|:---------|
|
||||
| storage\_type | $00 | 4 bits (high) |
|
||||
| name\_length | $00 | 4 bits (low) |
|
||||
| file\_name | $01 | 15 bytes |
|
||||
| reserved | $10 | 2 bytes |
|
||||
| last\_mod | $12 | 4 bytes |
|
||||
| file\_name\_case\_bits | $16 | 2 bytes |
|
||||
| creation | $18 | 4 bytes |
|
||||
| version | $1c | 1 byte |
|
||||
| min\_version | $1d | 1 byte |
|
||||
| access | $1e | 1 byte |
|
||||
| entry\_length | $1f | 1 byte |
|
||||
| entries\_per\_block | $20 | 1 byte |
|
||||
| file\_count | $21 | 2 byte |
|
||||
| bit\_map\_pointer | $23 | 2 bytes |
|
||||
| total\_blocks | $25 | 2 bytes |
|
74
XattrUtility.md
Normal file
74
XattrUtility.md
Normal file
@ -0,0 +1,74 @@
|
||||
# Introduction
|
||||
|
||||
Extended attributes (xattr), while (sort of) supported under linux, are somewhat of a second class citizen. ProFUSE makes use of them to reveal custom ProDOS information (such as resource forks, file types, and creator types). For debugging and verification, we present the `xattr` utility
|
||||
|
||||
# Compiling
|
||||
|
||||
Note: OS X has an `xattr` utility (with a different syntax). You can, of course, compile and use this one as well.
|
||||
|
||||
```
|
||||
g++ xattr.cpp -o xattr
|
||||
```
|
||||
|
||||
# Usage
|
||||
|
||||
|
||||
`xattr list filename [`_`attribute names`_` ...]`
|
||||
|
||||
`xattr dump filename [`_`attribute names`_` ...]`
|
||||
|
||||
`xattr read filename attribute`
|
||||
|
||||
`xattr write filename attribute`
|
||||
|
||||
|
||||
If no attribute names are specified, all attributes will be listed or dumped, accordingly. `read` and `write` read or write data from `stdin` or `stdout`, respectively.
|
||||
|
||||
# Examples
|
||||
```
|
||||
|
||||
qnap:/usr/local/src/profuse# ./xattr list /mnt/Text/Dynobricks
|
||||
com.apple.FinderInfo 32
|
||||
com.apple.TextEncoding 11
|
||||
prodos.AuxType 2
|
||||
prodos.FileType 1
|
||||
prodos.ResourceFork 844
|
||||
user.charset 9
|
||||
user.mime_type 10
|
||||
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
|
||||
qnap:/usr/local/src/profuse# ./xattr dump /mnt/Text/Dynobricks
|
||||
com.apple.FinderInfo: 32
|
||||
000000: 70 50 54 45 70 64 6f 73 00 00 00 00 00 00 00 00 pPTEpdos........
|
||||
000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
|
||||
com.apple.TextEncoding: 11
|
||||
000000: 4d 41 43 49 4e 54 4f 53 48 3b 30 MACINTOSH;0
|
||||
|
||||
prodos.AuxType: 2
|
||||
000000: 45 54 ET
|
||||
|
||||
prodos.FileType: 1
|
||||
000000: 50 P
|
||||
|
||||
prodos.ResourceFork: 844
|
||||
000000: 00 00 00 00 8c 00 00 00 3e 01 00 00 00 00 00 00 ........>.......
|
||||
000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
...
|
||||
000340: 00 00 00 00 5c 00 00 00 0c 00 00 00 ....\.......
|
||||
|
||||
user.charset: 9
|
||||
000000: 6d 61 63 69 6e 74 6f 73 68 macintosh
|
||||
|
||||
user.mime_type: 10
|
||||
000000: 74 65 78 74 2f 70 6c 61 69 6e text/plain
|
||||
|
||||
|
||||
```
|
||||
|
||||
`xattr` is not ProDOS/ProFUSE specific, so you can use it on other file systems. Assuming you can find other files with extended attributes...
|
18
newfs_pascal.md
Normal file
18
newfs_pascal.md
Normal file
@ -0,0 +1,18 @@
|
||||
# NAME
|
||||
|
||||
newfs\_pascal -- Create a new pascal file system
|
||||
|
||||
# SYNOPSIS
|
||||
|
||||
`newfs_pascal [-v volume_name] [-s size] [-f format] file`
|
||||
|
||||
# DESCRIPTION
|
||||
|
||||
`newfs_pascal` creates a new disk image and format it with an empty apple pascal file system. `newfs_pascal` may also be used with an actual device (eg, `/dev/disk0s1`), assuming you have appropriate permissions.
|
||||
|
||||
# OPTIONS
|
||||
|
||||
| `-v volume_name` | Specify the volume name. Default is based on the file name. |
|
||||
|:-----------------|:------------------------------------------------------------|
|
||||
| `-s size` | Specify the file size, in blocks. May use K or M qualifier. Default is 1600 blocks (800k) |
|
||||
| `-f format` | Specify the file format. Default is based on file name. |
|
Loading…
Reference in New Issue
Block a user