realbasic-nug
[Top] [All Lists]

Re: Best way to handle loss of ResourceFork

To: realbasic-nug@lists.realsoftware.com
Subject: Re: Best way to handle loss of ResourceFork
From: jda <jda@his.com>
Date: Thu, 31 Jul 2008 11:45:21 -0400
Authentication-results: mx.google.com; spf=neutral (google.com: 74.124.194.228 is neither permitted nor denied by best guess record for domain of realbasic-nug-bounces@lists.realsoftware.com) smtp.mail=realbasic-nug-bounces@lists.realsoftware.com
Delivered-to: listarchive@realsoftware.com
In-reply-to: <mailman.3370.1217517990.19703.realbasic-nug@lists.realsoftware.com>
References: <mailman.3370.1217517990.19703.realbasic-nug@lists.realsoftware.com>
Reply-to: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Sender: realbasic-nug-bounces@lists.realsoftware.com

> 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>


<Prev in Thread] Current Thread [Next in Thread>