On 10/18/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>
> On Sep 25, 2007, at 01:56, Christiaan Hofman wrote:
>
> > On 25 Sep 2007, at 5:29 AM, Adam R. Maxwell wrote:
> >
> >> On Sep 24, 2007, at 07:50, Christiaan Hofman wrote:
> >>
> >>> I see many problems with the file references.
> >>> - Files may not exist (especially when shared between different
> >>> computers).
> >>> - Files may be deleted/moved to trash/replaced
> >>>
> >>> So certainly the current BDSKFile objects are not sufficient.
> >>> Somehow
> >>> a non-existing file should remember the aliasdata for saving, and an
> >>> existing file should remember a (relative?) path in case it's
> >>> removed. I think we need a subclass of BDSKFSRefFile and
> >>> BDSKURLFile.
> >>
> >> I think a broken alias is expected behavior if the file is deleted,
> >> and I'm not convinced that accounting for it with a path is
> >> necessarily an improvement...I wonder what happens with the FSRef in
> >> that case, though? Watching it with the FSEvent stuff in Leopard
> >> would be the most useful approach, but again it's a lot of work for
> >> an
> >> edge case.
> >>
> >
> > I do think that people expect that when you replace a file (by
> > deleting one and adding another one in the same place), for example
> > using a script, keeps the linked file. I think the FSRef becomes
> > invalid in that case (though I'm not sure). If you look at NSDocument
> > (which uses FSRef) you see that when you delete the file, the proxy
> > icon is lost, while if you move the file the proxy icon is changed.
> >
> >> I definitely agree that if the file isn't present when the file
> >> object
> >> is instantiated, the alias/path that was used to instantiate it
> >> should
> >> be preserved. I thought that could be handled with a subclass of
> >> BDSKFile that's similar to BDSKURLFile (or replace it).
> >>
> >
> > That's possible. I'm not sure if it should be an alias+relative path
> > or alias+URL(absolute path).
>
> I've been doing a bit of homework trying to figure out what the
> relative path features in BDAlias can do. It turns out that aliases
> store a path, and will try that first before using file ID. There's a
> long thread about this at <
> http://www.cocoabuilder.com/archive/message/cocoa/2004/8/19/114982
> >, and it's documented at <
> http://developer.apple.com/technotes/tn2002/tn2053.html#TN001072
> >.
>
> Also, relative path aliases seem to work across systems, but I have to
> figure out if we can use this; I'm just mentioning it for now. Test
> code at the end of this message. I created an aliasData file on
> machine 1, then set up the same relative path structure on machine 2
> (../testDir/testFile) and copied the aliasData from machine 1 to
> machine 2. The second call using fullPathRelativeToPath: worked on
> machine 2 using the alias data created on machine 1.
>
> So we may be doing some unnecessary work by storing paths. Also, a
> file that's deleted would be resolved correctly using the original
> alias data, although you're right that FSRefs become invalid in that
> case.
>
> >>> Also the base path is a problem. For new databases there may not
> >>> be a
> >>> filename. And what is the base path for export/save as? And how is
> >>> it
> >>> passed to the file objects?
> >>
> >> It would have to be passed by the BibItem when saving, since it's the
> >> only object that connects the document and files.
> >>
> >
> > But how does BibItem know the filename?
>
> [[[self document] fileURL] path]...but it may not be available at that
> point in the save cycle.
I mean, in general. This is nil for new documents.
>>> But what about initially adding items to a new database? I think
> >>> they
> >>> should be represented by an FSRef and an absolute path (so the path
> >>> in the new BDSKFile subclass should be absolute, or both relative
> >>> and
> >>> absolute).
> >>
> >> Why a path as well as FSRef? For the trashing case?
> >
> > Yes. Otherwise deleting the file will give a BDSKFile object with
> > absolutely no information.
>
> So maybe we should just create new ones with a BDAlias ivar
> immediately, since those should work around the deletion problem?
>
> --
> adam
But not the new file problems.
Christiaan
#import <Foundation/Foundation.h>
> #import "BDAlias.h"
>
> int main (int argc, const char * argv[]) {
> NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
>
> if ([[[NSProcessInfo processInfo] arguments] count] > 1) {
> NSString *path = [[[NSProcessInfo processInfo] arguments]
> lastObject];
> NSLog(@"reading alias data from %@", path);
> NSData *data = [NSData dataWithContentsOfFile:path];
> if (0 == [data length]) exit(1);
>
> BDAlias *alias = [BDAlias aliasWithData:data];
> if (nil == alias) exit(1);
>
> NSLog(@"alias path is %@", [alias fullPath]);
>
> NSLog(@"full path relative to %@ is %@", @"../testDir",
> [alias fullPathRelativeToPath:@"../testDir"]);
> }
> else {
> BDAlias *alias = [BDAlias aliasWithPath:@"testFile"
> relativeToPath:@"../testDir"];
> NSData *data = [alias aliasData];
>
> if (0 == [data length]) exit(1);
> [data writeToFile:@"aliasData" atomically:NO];
> }
>
> [pool drain];
> return 0;
> }
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Bibdesk-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
