You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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=
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:
Bluetooth-Firmware-upd.T:
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:
In t_compare fs=00000000 tran=0X819600
in t_print fs=0X00000000
Bluetooth-Firmware-upd.T:
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 (( 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
The text was updated successfully, but these errors were encountered: