QRecall

Johannes

While testing I recalled (and restored) three deleted .pict files (old scans). The results are Aliases - at least Finder sees them as Alias, but their size is the same as the .pict-files that I deleted (had to restore them from Time Machine backup). I tried opening those Aliases with different Applications but no luck as Finder insists in seeing them as Aliases. Any idea why they became Aliases when restoring (recalling) them?

Johannes

James Bucanek

Johannes wrote:Any idea why they became Aliases when restoring (recalling) them?

I have no clue. I've never seen that happen.

What do the files look like if you list then in the terminal (ls -l)? And if you have GetFileInfo installed, it would be interesting to see what their file attributes are, and how they differ from the attributes of the original.

Also, try duplicating them in the Finder and see if the Finder still thinks they're alias files.

Johannes

Duplicating in Finder does not change anything.

Here some Terminal output:

ls -la@ in recall folder and in original folder (no difference):

-rwx--x--x@ 1 admin  staff  1092614 23 Mai  2002 bergkristal1.pict

	com.apple.FinderInfo	     32 



-rwx--x--x@  1 admin  staff  1092614 23 Mai  2002 bergkristal1.pict

	com.apple.FinderInfo	     32

xattr -l in recall folder and in original folder (looks like the same difference like with some other old files):

00000000  50 49 43 54 47 4B 4F 4E 01 00 00 46 FF 51 00 00  |PICTGKON...F.Q..|

00000010  00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00  |................|

00000020



00000000  50 49 43 54 47 4B 4F 4E 80 00 00 46 00 00 00 00  |PICTGKON...F....|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

GetFileInfo in recall folder and in original folder (difference: case of 1st and 8th letter in Attributes):

file: "/private/tmp/InstantRecall.501/QRecall-31387944473/bergkristal1.pict"

type: "PICT"

creator: "GKON"

attributes: Avbstclinmedz

created: 05/23/2002 10:57:09

modified: 05/23/2002 10:57:09



file: "/Volumes/Tscho/Privat/Elke/bergkristal1.pict"

type: "PICT"

creator: "GKON"

attributes: avbstclInmedz

created: 05/23/2002 10:57:09

modified: 05/23/2002 10:57:09

Johannes

James Bucanek

Johannes wrote:ls -la@ in recall folder and in original folder (no difference):

Well, the file got restored correctly. That's good news.

xattr -l in recall folder and in original folder (looks like the same difference like with some other old files):

00000000  50 49 43 54 47 4B 4F 4E 01 00 00 46 FF 51 00 00  |PICTGKON...F.Q..|

00000010  00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00  |................|

00000020



00000000  50 49 43 54 47 4B 4F 4E 80 00 00 46 00 00 00 00  |PICTGKON...F....|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

Similar, but not exactly. In this case one file has Finder flags of 0100 and the original has 8000. The value 0100 indicates kHasNoINITs (an obsolete OS 9 attribute), while 8000 mean kIsAlias. (Are these backwards by any chance?)

It would be interesting to find out what finder information QRecall read, and captured, when it got the file in the first place. And since you're running an alpha version of QRecall, you can do that.

:

Open the archive with this file and choose Archive > Dump. In the data section, check "File Package" "File Package: Details" and "Scan by Package". Uncheck every other option in the dialog. Click Dump (it may take awhile, during which QRecall will be frozen). Open the dump file with a text editor and find the file records for the 'bergkristal1.pict' file.

Johannes

It would be interesting to find out what finder information QRecall read, and captured, when it got the file in the first place.

Here are the file records; 4 of them; difference is in # and capture time and once gid (I guess that was the re-capture after TM restore).

[   216]: #166793 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-11 10:45:01 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=20(staff) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

[   216]: #656329 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-12 00:09:36 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=20(staff) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

[   224]: #676763 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-12 15:00:05 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=99(_unknown) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

[   216]: #811433 0301 FilePackage "bergkristal1.pict"

           captured 2010-12-12 21:42:05 +0100

           node flags=0x0000

           created=2002-05-23 10:57:09 +0200 modified=2002-05-23 10:57:09 +0200

           uid=501(admin) gid=20(staff) access=0x07 mode=0100711(rwx--x--x) acl=(null)

           type='PICT' creator='GKON' flags=[inited]

           extendedFlags=8000 putAwayID=0

           encoding hint=0

            fork '' [1092614]: 34 packages: 166759 166760 166761 166762 166763 166764 166765 166766 166767 166768 166769 166770 166771 166772 166773 166774 166775 166776 166777 166778 166779 166780 166781 166782 166783 166784 166785 166786 166787 166788 166789 166790 166791 166792

           icon=250

and choose Archive > Dump

Now I know what the Dump-Command is for. Is this alpha only? If not the Eclipse dots are missing in the menu. What is the diference between Archive>Dump and File>Dump??

(Are these backwards by any chance?)

I don't know. It's just what I copied from Terminal. Could this be a left over from Big/Little Endian issue between Intel and PowerPC machines? When I created this file I was on a PowerPC. Now I am on Intel. Just a thought ?

Johannes

James Bucanek

Johannes wrote:
Here are the file records; ...

Thanks, Johannes! As soon as I looked at those records, I knew exactly what was wrong.

Please download and install QRecall 1.2.0(25) alpha, which fixes this bug. The problem was a mismatch between the way extended finder information was captured and how it gets restored. I'm embarrassed to say that this was caused when I merged two branches of the QRecall project to create 1.2.0a24. Some recent optimizations in metadata handling got into a24, while others didn't.

The good news is that the errent code was isolated to the restore logic. All of the information in the archive is correct, and if you restore the same items using a25 they should be OK.

Now I know what the Dump-Command is for. Is this alpha only?

This command (and a few others) only appear in the alpha and beta releases, and are intended for debugging problems just like this.

What is the diference between Archive>Dump and File>Dump??

One of them works.

Could this be a left over from Big/Little Endian issue between Intel and PowerPC machines? When I created this file I was on a PowerPC. Now I am on Intel. Just a thought ?

It's a good thought. There were a few file system structures in 10.4 and 10.5 that didn't get swapped property during the early migration to Intel, but to my knowledge all of these have been fixed. For cross-platform compatibility, all structures are stored big-endien in the filesystem. So anything originally written using a PowerPC machine should be correct on the disk. The only possible problem would be Intel software that fails to swap the bytes when it reads the data.

Good catch!

Johannes

James Bucanek wrote: if you restore the same items using a25 they should be OK.

Confirmed: they are restored fine.

Thanks for fixing.

Johannes