Xojo Conferences
XDCMay2019MiamiUSA

Best way to handle loss of ResourceFork (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Threads
Next thread: OOP design question


Best way to handle loss of ResourceFork   -   jda
  Re: Best way to handle loss of ResourceFork   -   Don Jungk
  Re: Best way to handle loss of ResourceFork   -   Christian Schmitz
  Re: Best way to handle loss of ResourceFork   -   John Jobe
  Re: Best way to handle loss of ResourceFork   -   Joe Strout
  Re: Best way to handle loss of ResourceFork   -   Dennis Birch
  Re: Best way to handle loss of ResourceFork   -   Norman Palardy
  Re: Best way to handle loss of ResourceFork   -   GregO
  Re: Best way to handle loss of ResourceFork   -   Tim Jones
  Re: Best way to handle loss of ResourceFork   -   jda
  Re: Best way to handle loss of ResourceFork   -   James Sentman

Best way to handle loss of ResourceFork
Date: 31.07.08 15:25 (Thu, 31 Jul 2008 10:25:54 -0400)
From: jda
ResourceFork is deprecated and scheduled for oblivion, so I'm looking
for another solution to handle the following situation (on a Mac, of
course)

I have a series of ancillary text files whose names my app displays
to the user in a listbox. These files contain connection information
that my app uses to access different Internet sites. There is one
function (it doesn't matter what) that can be enabled or disabled,
and I want the user to see that in the listbox display.

My solution has been to add a resource of my own making to each file
that contains text, either "true" or "false". If "true", the name of
the file is displayed in italics in the listbox. If "false" it is
displayed in plain text. So all I need do is check the resource of
each file (there may be many hundreds of them) and then set the text
style of the listbox cell accordingly.

Without the resource fork, I can see only two solutions when I
iterate over each of these files. One is to open each file, read in
the data, determine if the function is enabled or not, close the
file, and then set the listbox. This is clearly a poor solution with
many hundreds of files to examine. The second solution I can think of
is to assign a different extension to the files (e.g. .en for
function enabled, .dis for function disabled, or some such thing),
that my app can examine as it iterates over the file names to
determine if the function is enabled or not. This also strikes me as
kludgey and prone to cause problems.

Basically I would like a way to determine a simple boolean setting of
a file without having to open it and parse its contents. The
ResourceFork was perfect for this. I'd appreciate any thoughts on the
replacements I've come up with, or any I haven't considered.

Jon

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 16:11 (Thu, 31 Jul 2008 10:11:00 -0500)
From: Don Jungk
On Thursday July 31 2008 9:25 am, jda wrote:
>
> Without the resource fork, I can see only two solutions when I
> iterate over each of these files. One is to open each file, read in
> the data, determine if the function is enabled or not, close the
> file, and then set the listbox. This is clearly a poor solution with
> many hundreds of files to examine. The second solution I can think of
> is to assign a different extension to the files (e.g. .en for
> function enabled, .dis for function disabled, or some such thing),
> that my app can examine as it iterates over the file names to
> determine if the function is enabled or not. This also strikes me as
> kludgey and prone to cause problems.
>
> Basically I would like a way to determine a simple boolean setting of
> a file without having to open it and parse its contents. The
> ResourceFork was perfect for this. I'd appreciate any thoughts on the
> replacements I've come up with, or any I haven't considered.
>
> Jon
>

If you are creating these files and they are not going to be edited by users,
then:
1) put something in the name of the file, like a "+" or "-".
2) pad the files to an even number of bytes for enabled and an odd number for
disabled. Then you don't have to open them, just read the length. A change of
encoding or line endings would mess this up.

DJ

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 01.08.08 00:04 (Fri, 1 Aug 2008 01:04:18 +0200)
From: Christian Schmitz
jda <<email address removed>> wrote:

> ResourceFork is deprecated and scheduled for oblivion, so I'm looking
> for another solution to handle the following situation (on a Mac, of
> course)

Well, before they disappear from RB I may add such a class to my
plugins.

So don't worry.

Gruß
Christian

-

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 15:43 (Thu, 31 Jul 2008 09:43:39 -0500)
From: John Jobe
Use a Virtual Volume until it is deprecated.

On Jul 31, 2008, at 9:25 AM, jda wrote:

> ResourceFork is deprecated and scheduled for oblivion, so I'm
> looking for another solution to handle the following situation (on a
> Mac, of course)
>
> I have a series of ancillary text files whose names my app displays
> to the user in a listbox. These files contain connection information
> that my app uses to access different Internet sites. There is one
> function (it doesn't matter what) that can be enabled or disabled,
> and I want the user to see that in the listbox display.
>
> My solution has been to add a resource of my own making to each file
> that contains text, either "true" or "false". If "true", the name of
> the file is displayed in italics in the listbox. If "false" it is
> displayed in plain text. So all I need do is check the resource of
> each file (there may be many hundreds of them) and then set the text
> style of the listbox cell accordingly.
>
> Without the resource fork, I can see only two solutions when I
> iterate over each of these files. One is to open each file, read in
> the data, determine if the function is enabled or not, close the
> file, and then set the listbox. This is clearly a poor solution with
> many hundreds of files to examine. The second solution I can think
> of is to assign a different extension to the files (e.g. .en for
> function enabled, .dis for function disabled, or some such thing),
> that my app can examine as it iterates over the file names to
> determine if the function is enabled or not. This also strikes me as
> kludgey and prone to cause problems.
>
> Basically I would like a way to determine a simple boolean setting
> of a file without having to open it and parse its contents. The
> ResourceFork was perfect for this. I'd appreciate any thoughts on
> the replacements I've come up with, or any I haven't considered.
>
> Jon

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 15:45 (Thu, 31 Jul 2008 08:45:24 -0600)
From: Joe Strout
On Jul 31, 2008, at 8:25 AM, jda wrote:

> I have a series of ancillary text files whose names my app displays
> to the user in a listbox. These files contain connection information
> that my app uses to access different Internet sites. There is one
> function (it doesn't matter what) that can be enabled or disabled,
> and I want the user to see that in the listbox display.
>
> My solution has been to add a resource of my own making to each file
> that contains text, either "true" or "false". If "true", the name of
> the file is displayed in italics in the listbox. If "false" it is
> displayed in plain text. So all I need do is check the resource of
> each file (there may be many hundreds of them) and then set the text
> style of the listbox cell accordingly.

This was a good solution only if this enabled/disabled state wasn't
particularly important to the function of the app. For example,
BBEdit used to store a little data in the resource fork about the
current cursor position and font size, but if that info got lost (as
could easily happen to a text file when transmitted by ftp, checked in/
out of subversion, etc.), it was no big loss -- it was just "extra"
data.

But if this is essential data, then I wouldn't consider this a very
good solution, as users who do transmit your files by ftp or try to
use them with svn or whatever will be disappointed when they break.

> Without the resource fork, I can see only two solutions when I
> iterate over each of these files. One is to open each file, read in
> the data, determine if the function is enabled or not, close the
> file, and then set the listbox. This is clearly a poor solution with
> many hundreds of files to examine.

That's not so clear to me. If you can put this enabled/disabled flag
at the start of the file, then it will be no slower to open the file
and read that much of it than it would be to open the resource fork
and read that resource.

If not, then I agree it's a somewhat harder case... but probably still
not going to be so much slower that users would actually notice the
difference.

Best,
- Joe

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 15:53 (Thu, 31 Jul 2008 07:53:04 -0700)
From: Dennis Birch
On Thu, Jul 31, 2008 at 7:25 AM, jda <<email address removed>> wrote:

> Basically I would like a way to determine a simple boolean setting of a file
> without having to open it and parse its contents. The ResourceFork was
> perfect for this. I'd appreciate any thoughts on the replacements I've come
> up with, or any I haven't considered.

But even with a ResourceFork you ARE opening the file to read the
resource. It's opening it in a different way than reading the data
fork, but it's still opening it.

I would consider adding your boolean to a proprietary file header in
the data fork. You could also change to an XML format, but that sounds
like overkill for the needs you have described.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 15:56 (Thu, 31 Jul 2008 08:56:47 -0600)
From: Norman Palardy

On 31-Jul-08, at 8:25 AM, jda wrote:

> ResourceFork is deprecated and scheduled for oblivion

Apple has basically said "don't use resource fork resources"
But that does not mean you cannot use resources
They'd just be in the data fork

That said you might look at other means of storing this data so it's
easy to get at

When you initially open the application and list all the files load
the meta data about them into an in memory database
Then when you add / remove or alter things about the files you can
update that database
This should be an order of magnitude faster than resources



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 16:25 (Thu, 31 Jul 2008 11:25:51 -0400)
From: GregO
On Jul 31, 2008, at 10:25 am, jda wrote:

> ResourceFork is deprecated and scheduled for oblivion, so I'm
> looking for another solution to handle the following situation (on a
> Mac, of course)
>
> I have a series of ancillary text files whose names my app displays
> to the user in a listbox. These files contain connection information
> that my app uses to access different Internet sites. There is one
> function (it doesn't matter what) that can be enabled or disabled,
> and I want the user to see that in the listbox display.
>
> My solution has been to add a resource of my own making to each file
> that contains text, either "true" or "false". If "true", the name of
> the file is displayed in italics in the listbox. If "false" it is
> displayed in plain text. So all I need do is check the resource of
> each file (there may be many hundreds of them) and then set the text
> style of the listbox cell accordingly.
>
> Without the resource fork, I can see only two solutions when I
> iterate over each of these files. One is to open each file, read in
> the data, determine if the function is enabled or not, close the
> file, and then set the listbox. This is clearly a poor solution with
> many hundreds of files to examine. The second solution I can think
> of is to assign a different extension to the files (e.g. .en for
> function enabled, .dis for function disabled, or some such thing),
> that my app can examine as it iterates over the file names to
> determine if the function is enabled or not. This also strikes me as
> kludgey and prone to cause problems.
>
> Basically I would like a way to determine a simple boolean setting
> of a file without having to open it and parse its contents. The
> ResourceFork was perfect for this. I'd appreciate any thoughts on
> the replacements I've come up with, or any I haven't considered.

Since you obviously want the data stored with the file, I see two
possibilities:

1. Add a boolean to the beginning (or end) of each file using a
binaryStream and read only that bit and then close the file. I
wouldn't think this would be too taxing to do.

2. Save your files as "Packages" the way Keynote or Pages does so that
a "File" can store more than just one file's worth of info.

Greg

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 16:27 (Thu, 31 Jul 2008 08:27:15 -0700)
From: Tim Jones
On Jul 31, 2008, at 7:25 AM, jda wrote:

> ResourceFork is deprecated and scheduled for oblivion, so I'm
> looking for another solution to handle the following situation (on a
> Mac, of course)

The Resource Fork as you know it is deprecated, but that doesn't mean
that you still can't store resources. I know that you will prefer to
continue with a single file scenario (more comments on that below),
but Apple has dictated that we're to do it the "new" way and that
"new" way is bundles. Look at rtfd, pages, key, etc. files - they're
actually folders containing the necessary bits of information for the
file.

While I don't think that either way is better from a developmental
standpoint, I do find the abuse of inode consumption created by a
bundle hierarchy versus the original multi-fork files to be a bit bold
- disks are huge, gobble 'em up!. I'm sure that Apple has their
reasons, as I'm also sure they'll never share those reasons openly
with the rest of us, and the RS team are only doing what they need to
do to try and catch up with Apple's platform.

> I have a series of ancillary text files whose names my app displays
> to the user in a listbox. These files contain connection information
> that my app uses to access different Internet sites. There is one
> function (it doesn't matter what) that can be enabled or disabled,
> and I want the user to see that in the listbox display.
>
> My solution has been to add a resource of my own making to each file
> that contains text, either "true" or "false". If "true", the name of
> the file is displayed in italics in the listbox. If "false" it is
> displayed in plain text. So all I need do is check the resource of
> each file (there may be many hundreds of them) and then set the text
> style of the listbox cell accordingly.

That sounds like a great use for an XML plist file. Why create
multiple files (again, inode consumption) when you can easily
generate, parse and maintain a single XML file that contains all of
this info with the tools RB offers today.

> Without the resource fork, I can see only two solutions when I
> iterate over each of these files. One is to open each file, read in
> the data, determine if the function is enabled or not, close the
> file, and then set the listbox. This is clearly a poor solution with
> many hundreds of files to examine. The second solution I can think
> of is to assign a different extension to the files (e.g. .en for
> function enabled, .dis for function disabled, or some such thing),
> that my app can examine as it iterates over the file names to
> determine if the function is enabled or not. This also strikes me as
> kludgey and prone to cause problems.
>
> Basically I would like a way to determine a simple boolean setting
> of a file without having to open it and parse its contents. The
> ResourceFork was perfect for this. I'd appreciate any thoughts on
> the replacements I've come up with, or any I haven't considered.

But, you were opening and parsing the file each time you accessed its
resource fork.

Again, change your layout to place all of your information into a
single XML file and manage it with the tools that RB offers - one
file, easy access, no resource fork deprecation worries.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 16:45 (Thu, 31 Jul 2008 11:45:21 -0400)
From: jda
>
> > My solution has been to add a resource of my own making to each file
>> that contains text, either "true" or "false". If "true", the name of
>> the file is displayed in italics in the listbox. If "false" it is
>> displayed in plain text. So all I need do is check the resource of
>> each file (there may be many hundreds of them) and then set the text
> style of the listbox cell accordingly.

>
>But if this is essential data, then I wouldn't consider this a very
>good solution, as users who do transmit your files by ftp or try to
>use them with svn or whatever will be disappointed when they break.

First, thanks to everyone who has replied. The consensus seems to be
to store a boolean at the beginning or end of the file and retrieve
it quickly. Since I want the files to be backward compatible, at the
end would make sense. One problem is going to be that my users are
able to change this setting (programatically), and so when I roll out
the new method in a version of RB that doesn't support resource
forks, I'll have no idea what that setting was, and would have to
assume all old files are set to "false". The only solution for that
is to open the file, find the byte that has the value, and read that
in. Only experimentation will tell me if that's fast enough.

FWIW, the resource fork solution has worked well for me since 1998.
Although there are theoretical issues (like loss of the resource fork
when ftp'ing), in practice they are very rarely encountered (in fact,
never encountered in my user's experience).

Thanks again.

Jon


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Best way to handle loss of ResourceFork
Date: 31.07.08 18:30 (Thu, 31 Jul 2008 13:30:04 -0400)
From: James Sentman

On Jul 31, 2008, at 10:56 AM, Norman Palardy wrote:

>
> Apple has basically said "don't use resource fork resources"
> But that does not mean you cannot use resources
> They'd just be in the data fork

And you might want to label the resource fork as dont use for future
development. But it should not be removed simply because of how truly
pervasive it was in preOSX and early OSX days. The resource fork was
used for EVERYTHING in the mac world up until very recently. So while
I wouldn't design a file format today that needed it, I still need to
be able to read the files I created in the past and the files that
other apps created in the past. There are a huge number of these out
there that we all still need to be able to read.

I got a nice response from Geoff at RS about this when I emailed him
my concerns and he is looking into perhaps pulling the resource fork
support out into a separate and potentially open sourced plugin. This
way it would remain around for those of us that needed it and yet not
continue to clutter up the RS toolbox of things they need to maintain
and test. I thought this was a perfectly reasonable response and would
be quite happy if that could happen.

So if you wish to have this around for maintaining compatibility with
older versions and older files (and really, they aren't that old!) you
might drop RS a note supporting having someone take the time to pull
those things out and into a plugin, rather than just removing them
completely. I haven't heard yet that any final decision was made,
there is some work involved in doing this, but I think it would be
well spent.

Thanks,
James

James Sentman http://sentman.com http://MacHomeAutomation.com



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>