Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Ffile size - how do you treat file ends?

  1. #1

    Default Ffile size - how do you treat file ends?

    Different tools I use do different things. If I use yaze's W command to write a file out to the host, or use cpmtools cpmcp to copy a file, it maintains the size down to the byte by using the Bc field. At the same time CP/M 2.2 does not support this method/field.

    I'm working on a CRC32 tool to see if I can do it, so far it is coming along, but my question is - should I support this field when determining the end of the file? If so, then it would result in only running X bytes of the last record through the CRC generator, but if not, it would do the entire 128 byte record. I've also noticed that some files get padded with the 1F character, but still there is no way to know if those 1F's should belong to the file or it was padded.

    I could grab the Bc and support it if present, but the OS won't update it anyway so I'm not sure what the point is unless the tool is used on something newer where it would make sense. Maybe it won't hurt to support it.

    Will CP/M 2.2 alter the Bc field?

  2. #2

    Default

    CP/M 3 use of the BC field is supposed to be backward compatible - i.e. CP/M 2.2 should not alter it (I think). They endeavored to make all of the CP/M 3 extensions to the filesystem "benign" when a disk was accessed by CP/M 2.2. The directory label, timestamps, and passwords were all designed to be ignored (and left un-touched) by CP/M 2.2.

    Are you seeing padding of 1F? or is it 1A? Typically, programs will pad with 1A (Ctrl-Z, EOF). However, you can't assume that 1A is padding unless you know what kind of file it is (text or binary). I do see some binary files get padded with 1A, but the only way to know is to know what kind of file it is - and even more, such as where the last byte of initialized memory was (in a .COM file).

    I guess the risk is that you might have two text files that are otherwise identical but differ in the bytes following the Ctrl-Z, and their CRCs won't reflect the fact that they are "logically" identical. How will you be using the CRC results?
    - Doug

  3. #3

    Default

    Sorry, Doug, I am mistaken, I was thinking 1A but write 1F.

    Mostly using the results to know if a file is good or bad, the same or different.

    Does CP/M 3 give an option to write a half record?

  4. #4

    Default

    CP/M 3 allows you to set the BC (byte count), after writing the last (full) record. In other words, you write the last record and specify the actual EOF somewhere within that last record. Function 30 (SET FILE ATTRIBUTES) was extended to allow setting the byte count field from the FCB. Not real pretty, but got the job done. PIP would use it for text files, although I think it also padded with 1A (at least one 1A was required either way). Not sure whether programs like RMAC also set byte count in files like PRN and SYM. Also not sure about editors (though would have to be written specifically to detect CP/M 3 - or at least to know about it). I have a CP/NET server (in JAVA) that creates the byte count field for CP/M 3 to use (CP/M 2.2 ignores it).
    - Doug

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,979
    Blog Entries
    18

    Default

    But then, if you write a file on CP/M 3 and use the bc field and derive a checksum for it, the 2.2 checksum will be wrong, no?

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,979
    Blog Entries
    18

    Default

    If you PIP a file in CP/M 3, does the entire last 128-byte block get copied regardless of the bc field?

  7. #7

    Default

    Quote Originally Posted by Chuck(G) View Post
    If you PIP a file in CP/M 3, does the entire last 128-byte block get copied regardless of the bc field?
    read and write still work on 128-byte records. Nothing about those operations changes. Checking (or setting) the byte count is a voluntary operation that the programmer may choose to use. The default value for the BC field is 0 which means "full record".
    - Doug

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,979
    Blog Entries
    18

    Default

    That's what I suspected. I'll venture that few programs use the bc feature.

  9. #9

    Default

    Quote Originally Posted by Chuck(G) View Post
    That's what I suspected. I'll venture that few programs use the bc feature.
    Most programs didn't need to. But it was nice to have in some situations.
    - Doug

  10. #10

    Default

    Alan, short answer is probably that you need to ignore the BC field. But even then, it is possible for text files to have different data after the first Ctrl-Z, as I don't think copy/edit programs will make any effort to retain exact data after the first Ctrl-Z. So, there may be circumstances where the file CRC differs but the files are actually identical, logically speaking.
    - Doug

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •