Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fsdiff creates spurious multiple transcript lines #217

Open
pdarragh opened this issue Jul 15, 2009 · 0 comments
Open

fsdiff creates spurious multiple transcript lines #217

pdarragh opened this issue Jul 15, 2009 · 0 comments

Comments

@pdarragh
Copy link
Contributor

When doing a create transcript. A file that is in many multiple transcripts will show up as both a file to be created or removed. For example a file that shows up 32 times in different transcripts has

I did an fsdiff -Ccsha1 and the resulting file had
f /Library/Receipts/db/a.receiptdb 0600 96 0 1246534616 301826048 57Hpc4vgQ4rGLKOBANhUHxBfWtg=

  • f /Library/Receipts/db/a.receiptdb 0600 96 0 1245725942 295358464 7Dy0zKw4xkDnR7j7oRKWywDDTKg=

Now if you do an apply on that same directory you will get two apply transcripts, but an older one will overwrite a newer one.

% sudo ./fsdiff -Acsha1 /Library/Receipts/db
Global-Config-Leo-090709.T:

  • f /Library/Receipts/db/a.receiptdb 0600 96 0 1247177354 302125056 h/xg74sMy1ZxwqTAvbI53qfYaEM=
    Bluetooth-Firmware-upd.T:
  • f /Library/Receipts/db/a.receiptdb 0600 96 0 1245725942 295358464 7Dy0zKw4xkDnR7j7oRKWywDDTKg=

I put a bunch of print statements in various spots and it seems that t_compare is being called with a null fs argument. Thus the filename compare is showing that the file system needs updating one extra time.

I don't think it is specific to my setup. It seems that fsdiff is calling the comparison one too many times with a null file path.

I am not sure why this doesn't happen a lot! It may just be a random pointer corruption from the number of transcripts. I have added a few more print statements and it is more confusing.

% sudo ./fsdiff -Acsha1 /Library/Receipts/db
In t_compare fs=0XBFFFE060 tran=0X804600
fs->pi_name = "/Library/Receipts/db"
In t_compare fs=0XBFFFDAF0 tran=0XB49600
fs->pi_name = "/Library/Receipts/db/a.receiptdb"
tprint call #1
in t_print fs=0XBFFFDAF0
Global-Config-Leo-090709.T:

  • f /Library/Receipts/db/a.receiptdb 0600 96 0 1247177354 302125056 h/xg74sMy1ZxwqTAvbI53qfYaEM=
    In t_compare fs=00000000 tran=0X819600
    in t_print fs=0X00000000
    Bluetooth-Firmware-upd.T:
  • f /Library/Receipts/db/a.receiptdb 0600 96 0 1245725942 295358464 7Dy0zKw4xkDnR7j7oRKWywDDTKg=
    In t_compare fs=00000000 tran=0X800000

In this case it compares the directory, which is fine and nothing prints. It then then compares the file and prints the correct transcript line with the first possible call to the transcript print routine. Good so far.

Then it calls t_compare with a null file system pointer and a valid transcript.

I think that the problematic code is at line 480 in the transcript.c file.
/*

  • If the transcript is at EOF, and we've exhausted the filesystem,
  • just return T_MOVE_FS, as this will cause transcript() to return.
    */
    if (( tran->t_eof ) && ( fs == NULL )) {
    return T_MOVE_FS;
    }

And that the logic is that this should return in either case and it should be an 'or' rather than an 'and' operation. You want to return from t_compare immediately if you have reached the end of the file system. Otherwise it ends up doing a compare on a null pointer, then it will execute the code thinking that the file is in the transcript and not the filesystem.

Original comment by: shannahs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant