Persistant file specifiers?
Mike Whooley
find anything on deja/google.
What's the best way to persistantly store a file specification? Obviously
a FSSpec (or volume number and dir ID) isn't much use, since this won't
work for removeable volumes across a reboot.
Aliases seem ideal, but is there a way to write these to disk (as
distinct from creating an Alias File for each file I want to specify).
Any suggestions much appreciated,
Mike Whooley.
John Selhorst
wrote:
You can write alias handles to disk. Look at 'alis' resources. You can
also write them to the data fork. (I haven't tried it.) An alias
handle is just handle to a bunch of data.
Johnny
Mike Whooley
Selhorst at johns_...@sonic.net wrote on 7/2/01 4:30 PM:
> You can write alias handles to disk. Look at 'alis' resources. You can
> also write them to the data fork. (I haven't tried it.) An alias
> handle is just handle to a bunch of data.
I tried writing them to the data fork, but while the userType and aliasSize
fields were ok, the private data didn't seem to be (parameter error when
I tried to resolve the alias).
Saving them as resources could be a roundabout way of doing it, thanks!
Mike.
Chad J McQuinn
> I tried writing them to the data fork, but while the userType and aliasSize
> fields were ok, the private data didn't seem to be (parameter error when
> I tried to resolve the alias).
This is one of the cases where the toolbox structs and headers can mislead
you. The AliasRecord is a template of how the data in an AliasHandle
looks:
struct AliasRecord {
OSType userType;
unsigned short aliasSize;
};
These two fields are followed in memory by the actual alias data. You
really don't need to know anything about this struct, and in fact I have
never used it. All of the system routines that give you an alias, return a
handle. So you can do this:
-----
AliasHandle myAlias;
// do something, like call NewAlias, that gives you back an alias
Handle myHandle = (Handle)myAlias;
-----
then you can get its size with GetHandleSize, and (after locking it)
derefence it to get a pointer to the data. So if 'myFile' is an open data
fork reference number of the file you want to write to, you could do:
----
long mySize = ::GetHandleSize(myHandle);
::HLock(myHandle);
::FSWrite(myFile, &mySize, *myHandle);
----
and of course add the apropriate error checking. When you want to retrieve
the data, first figure out the size (which you must record in addition to
the data), then do something like this:
----
long savedAliasSize = (whatever the size of your saved alias is);
Handle myHandle = ::NewHandle(savedAliasSize);
::HLock(myHandle);
::FSRead(myFile, &savedAliasSize, *myHandle);
----
Then if you want to call alias manager routines, you will need to cast the
handle to an AliasHandle.
-Chad
Eden Smallwood
€ In article <B76659F7.233B%w...@mac.com>, Mike Whooley <w...@mac.com> wrote:
€ > I tried writing them to the data fork, but while the userType and aliasSize
€ > fields were ok, the private data didn't seem to be (parameter error when
€ > I tried to resolve the alias).
€
€ This is one of the cases where the toolbox structs and headers can mislead
€ you. The AliasRecord is a template of how the data in an AliasHandle
€ looks:
€
€ struct AliasRecord {
€ OSType userType;
€ unsigned short aliasSize;
€ };
€
€ These two fields are followed in memory by the actual alias data.
Doesn't NewAliasMinimal() give you a record that's a consistent size?
Eden
Mike Whooley
zeppe...@geocities.com wrote on 7/2/01 6:50 PM:
According to the docs, it uses the standard alias structure, but only fills
in part of the record.
Mike.
Mike Whooley
huske...@mac.com wrote on 7/2/01 5:28 PM:
> In article <B76659F7.233B%w...@mac.com>, Mike Whooley <w...@mac.com> wrote:
>> I tried writing them to the data fork, but while the userType and aliasSize
>> fields were ok, the private data didn't seem to be (parameter error when
>> I tried to resolve the alias).
>
> This is one of the cases where the toolbox structs and headers can mislead
> you. The AliasRecord is a template of how the data in an AliasHandle
> looks:
>
> struct AliasRecord {
> OSType userType;
> unsigned short aliasSize;
> };
>
> These two fields are followed in memory by the actual alias data. You
> really don't need to know anything about this struct, and in fact I have
> never used it. All of the system routines that give you an alias, return a
> handle. So you can do this:
[snip]
Thanks Chad!
It does complicate things, since the PC version just keeps a pathname in the
struct for every file, whereas the Mac version will have to keep a reference
to an entirely separate data structure/resource for the aliases. At least I
do get that extra degree of robustness though.
Thanks again,
Mike.
Mike Whooley
7/3/01 10:48 AM:
> in article 020720011050241413%zeppe...@geocities.com, Eden Smallwood at
> zeppe...@geocities.com wrote on 7/2/01 6:50 PM:
>> Doesn't NewAliasMinimal() give you a record that's a consistent size?
>
> According to the docs, it uses the standard alias structure, but only fills
> in part of the record.
Now that I think about this, it may just fill in the fixed-length fields, so
you may be right. I'll take a look, thanks.
Mike.
Mike Whooley
7/3/01 11:27 AM:
Yup, NewAliasMinimal() returns an alias struct fixed at 154 bytes.
Mike.
Simon Fraser
John Selhorst <johns_...@sonic.net> wrote:
You can use AliasHandles to store a persistent file specification, but
it does have its downsides. If the user reformats their drive, or copies
stuff across volumes, then the Alias Manager can get very confused at
alias resolution time, and do anything between quickly failing to
resolve the alias, to putting up UI asking the user to mount volumes,
to taking an extraordinarily long time to resolve the alias, and finally
failing.
So, there are some circumstances in which it might be better to just
store a filename and keep the files in a known location, or to store
a relative path to some known-stable root directory.
Simon
--
Simon Fraser <mailto:sm...@smfr.org> <http://www.smfr.org/>
(Professional driver on closed road)
meeroh
Simon Fraser <sm...@smfr.org> wrote:
>the Alias Manager can get very confused at
>alias resolution time, and do anything between quickly failing to
>resolve the alias, to putting up UI asking the user to mount volumes,
>to taking an extraordinarily long time to resolve the alias, and finally
>failing.
You forgot "resolving the alias to a completely random file on the new
disk" :-)
meeroh
--
You can get random signatures if you put text files into a folder called "Random Signatures" in your Preferences folder.
Eric Albert
> You can use AliasHandles to store a persistent file specification, but
> it does have its downsides. If the user reformats their drive, or copies
> stuff across volumes, then the Alias Manager can get very confused at
> alias resolution time, and do anything between quickly failing to
> resolve the alias, to putting up UI asking the user to mount volumes,
> to taking an extraordinarily long time to resolve the alias, and finally
> failing.
You can, though, use various flags when resolving aliases to ensure that
no UI is presented, that volumes aren't mounted, and that a fast search
happens. Depending on where you're getting aliases from, those can be
viable options.
-Eric
--
Eric Albert ejal...@stanford.edu
http://www.stanford.edu/~ejalbert/
Mike Whooley
mac...@meeroh.org wrote on 7/4/01 8:19 PM:
> In article <smfr-E84128.1...@virt-reader.news.rcn.net>,
> Simon Fraser <sm...@smfr.org> wrote:
>
>> the Alias Manager can get very confused at
>> alias resolution time, and do anything between quickly failing to
>> resolve the alias, to putting up UI asking the user to mount volumes,
>> to taking an extraordinarily long time to resolve the alias, and finally
>> failing.
>
> You forgot "resolving the alias to a completely random file on the new
> disk" :-)
Ok now stop it you guys, you're scaring me!
There was I thinking aliases were the Mac nirvana, when in truth I should
just go back and use pathnames ;)
Mike.
meeroh
wrote:
>There was I thinking aliases were the Mac nirvana, when in truth I should
>just go back and use pathnames ;)
They are very close to the Mac nirvana, but when they fail, they can
fail pretty spectacularly :-)
Eden Smallwood
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <macdev-A4EB27....@senator-bedfellow.mit.edu>, meeroh <mac...@meeroh.org> wrote:
€ In article <B769F1C0.2B0E%w...@mac.com>, Mike Whooley <w...@mac.com>
€ wrote:
€
€ >There was I thinking aliases were the Mac nirvana, when in truth I should
€ >just go back and use pathnames ;)
€
€ They are very close to the Mac nirvana, but when they fail, they can
€ fail pretty spectacularly :-)
I would imagine that taking almost 10 seconds, ( 590+ ticks on my G3 )
to look for a file it can't find would qualify as spectacular, as well.
This will happen when the alias refers to a volume which is not mounted,
and the mounting is attempted, and the mounting will fail.
As Eric Albert mostly stated, the answer, I think, if your app can live
with these abilities, is to use ::MatchAlias() instead of ::ResolveAlias(),
and to set flags which will search multiple volumes if they're there, yet
make no attempt to mount them if they're not, and do a fast search, etc.
With this setup, an alias is pretty nirvanic.
Eden
PS: When I went to post this, YA Newswatcher told me "The poster wants
an email response as well, so the email response is checked too". Is
that true, meeroh? And if so, how did you do that?
€ meeroh
meeroh
Eden Smallwood <zeppe...@geocities.com> wrote:
>PS: When I went to post this, YA Newswatcher told me "The poster wants
>an email response as well, so the email response is checked too". Is
>that true, meeroh? And if so, how did you do that?
I turned it on in MT-NW preferences :-)
What it does it put this in my headers:
Mail-Copies-To: poster
and therefore your newsreader does that.
hth
meeroh
--
The contents of text files in a folder called "Random Signatures" in your Preferences folder are used as random signatures.