https://forums.qrecall.com/posts/list/3.page JForum - http://www.jforum.net
Johannes

]]> https://forums.qrecall.com/posts/preList/300/1389.page https://forums.qrecall.com/posts/preList/300/1389.page GMT 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.]]> https://forums.qrecall.com/posts/preList/300/1391.page https://forums.qrecall.com/posts/preList/300/1391.page GMT
Here some Terminal output:

ls -la@ in recall folder and in original folder (no difference):
[code]-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 [/code]

xattr -l in recall folder and in original folder (looks like the same difference like with some other old files):
[code]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[/code]

GetFileInfo in recall folder and in original folder (difference: case of 1st and 8th letter in Attributes):
[code]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[/code]

Johannes


]]> https://forums.qrecall.com/posts/preList/300/1392.page https://forums.qrecall.com/posts/preList/300/1392.page GMT Well, the file got restored correctly. That's good news.

[quote]xattr -l in recall folder and in original folder (looks like the same difference like with some other old files):
[code]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[/code][/quote]
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.]]> https://forums.qrecall.com/posts/preList/300/1393.page https://forums.qrecall.com/posts/preList/300/1393.page GMT 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).
[code][ 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[/code]

[quote]and choose Archive > Dump[/quote]
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??

[quote](Are these backwards by any chance?) [/quote]
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
]]> https://forums.qrecall.com/posts/preList/300/1394.page https://forums.qrecall.com/posts/preList/300/1394.page GMT Here are the file records; ...[/quote]
Thanks, Johannes! As soon as I looked at those records, I knew exactly what was wrong.

Please download and install [url=http://www.qrecall.com/release/QRecall_1.2.0a25.dmg]QRecall 1.2.0(25) alpha[/url], 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.

[quote]Now I know what the Dump-Command is for. Is this alpha only?[/quote]
This command (and a few others) only appear in the alpha and beta releases, and are intended for debugging problems just like this.

[quote]What is the diference between Archive>Dump and File>Dump??[/quote]
One of them works. ;)

[quote]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 ?[/quote]
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!]]> https://forums.qrecall.com/posts/preList/300/1397.page https://forums.qrecall.com/posts/preList/300/1397.page GMT Confirmed: they are restored fine.

Thanks for fixing.

Johannes]]> https://forums.qrecall.com/posts/preList/300/1398.page https://forums.qrecall.com/posts/preList/300/1398.page GMT