Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #70004 > unrolled thread

Finder copies folder when I try to open it. Why?

Back to article view | Back to comp.sys.mac.system

Contents

  Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 06:30 -0500
    Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-20 12:49 +0000
      Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 10:07 -0500
        Re: Finder copies folder when I try to open it.  Why? Barry Margolin <barmar@alum.mit.edu> - 2015-02-20 11:04 -0500
          Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 11:58 -0500
        Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-20 17:36 +0000
          Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 12:53 -0500
            Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-20 20:14 +0000
              Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 17:38 -0500
                Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 17:55 -0500
                  Re: Finder copies folder when I try to open it.  Why? dempson@actrix.gen.nz (David Empson) - 2015-02-21 17:08 +1300
                    Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-21 15:29 +0000
                      Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-21 13:26 -0500
                        Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-21 20:35 +0000
                          Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-21 22:25 -0500
                            Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-22 15:43 +0000
                Re: Finder copies folder when I try to open it.  Why? Jolly Roger <jollyroger@pobox.com> - 2015-02-20 22:59 +0000
                  Re: Finder copies folder when I try to open it.  Why? Nelson <nelson@nowhere.com> - 2015-02-20 18:47 -0500

#70004 — Finder copies folder when I try to open it. Why?

This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
images in folders that I want iView MediaPro to generate catalogs for.  
Because you can't script iView to do this directly, I tell the Finder 
to open the folder using iView because, if you drop a folder on iView 
it catalogs it. (repeat: tell application "Finder" to open nextFolder 
using mediaPro).  Works like a charm... except

There are two folders out of about 100 where the Finder first makes a 
copy of the folder and then passes the copy to iView.  I can't see any 
difference between these folders and all the others.  As far as I can 
tell all the permissions and ownerships are the same.

Manually dragging the folder onto iView works as expected, ie it 
generates a catalog and no copy of the original folder is made.

It seems as if the Finder is treating the folder as a "stationary pad" 
but, of course, there is no "stationary pad" option for folders or, if 
there is, "Get Info" doesn't show it.

Any ideas?

-- 
Nelson

[toc] | [next] | [standalone]

#70013

On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
> This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
> images in folders that I want iView MediaPro to generate catalogs for.  
> Because you can't script iView to do this directly, I tell the Finder 
> to open the folder using iView because, if you drop a folder on iView 
> it catalogs it. (repeat: tell application "Finder" to open nextFolder 
> using mediaPro).  Works like a charm... except
>
> There are two folders out of about 100 where the Finder first makes a 
> copy of the folder and then passes the copy to iView.  I can't see any 
> difference between these folders and all the others.  As far as I can 
> tell all the permissions and ownerships are the same.
>
> Manually dragging the folder onto iView works as expected, ie it 
> generates a catalog and no copy of the original folder is made.
>
> It seems as if the Finder is treating the folder as a "stationary pad" 
> but, of course, there is no "stationary pad" option for folders or, if 
> there is, "Get Info" doesn't show it.
>
> Any ideas?

I haven't ever used iView, but I have scripted Finder plenty through the
years and haven't ever heard of such Finder behavior. Are you sure it is
Finder, and not iView, that is creating the duplicate copy? Isn't it
possible that Finder is telling iView to open the folder, and then iView
is creating a duplicate and opening that? Have you checked with iView
support to see if they might be able to explain this behavior?

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70018

On Fri, 20 Feb 2015 07:49:02 -0500, Jolly Roger wrote
(in article <ckoopuFsvveU2@mid.individual.net>):

> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>> This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
>> images in folders that I want iView MediaPro to generate catalogs for.  
>> Because you can't script iView to do this directly, I tell the Finder 
>> to open the folder using iView because, if you drop a folder on iView 
>> it catalogs it. (repeat: tell application "Finder" to open nextFolder 
>> using mediaPro).  Works like a charm... except
>> 
>> There are two folders out of about 100 where the Finder first makes a 
>> copy of the folder and then passes the copy to iView.  I can't see any 
>> difference between these folders and all the others.  As far as I can 
>> tell all the permissions and ownerships are the same.
>> 
>> Manually dragging the folder onto iView works as expected, ie it 
>> generates a catalog and no copy of the original folder is made.
>> 
>> It seems as if the Finder is treating the folder as a "stationary pad" 
>> but, of course, there is no "stationary pad" option for folders or, if 
>> there is, "Get Info" doesn't show it.
>> 
>> Any ideas?
> 
> I haven't ever used iView, but I have scripted Finder plenty through the
> years and haven't ever heard of such Finder behavior. Are you sure it is
> Finder, and not iView, that is creating the duplicate copy? Isn't it
> possible that Finder is telling iView to open the folder, and then iView
> is creating a duplicate and opening that? Have you checked with iView
> support to see if they might be able to explain this behavior?

No, I'm sure it's not iView because I can use any other application 
that accepts a folder dropped on it... even an applescript droplet... 
and it does the same thing.  And I have found other folders that do the 
same thing.  All I can figure is that the Finder is treating the folder 
as a file and checking for where the "stationery" bit would be if it 
were a file and finding random data.  It must be peculiar to scripting 
the finder.  Maybe it has something to do with the way I am specifying 
"nextfolder".  I need to play with it some more.

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70019

In article <0001HW.D10CB7CD000DA8EAB01029BF@news.astraweb.com>,
 Nelson <nelson@nowhere.com> wrote:

> On Fri, 20 Feb 2015 07:49:02 -0500, Jolly Roger wrote
> (in article <ckoopuFsvveU2@mid.individual.net>):
> 
> > On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
> >> This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
> >> images in folders that I want iView MediaPro to generate catalogs for.  
> >> Because you can't script iView to do this directly, I tell the Finder 
> >> to open the folder using iView because, if you drop a folder on iView 
> >> it catalogs it. (repeat: tell application "Finder" to open nextFolder 
> >> using mediaPro).  Works like a charm... except
> >> 
> >> There are two folders out of about 100 where the Finder first makes a 
> >> copy of the folder and then passes the copy to iView.  I can't see any 
> >> difference between these folders and all the others.  As far as I can 
> >> tell all the permissions and ownerships are the same.
> >> 
> >> Manually dragging the folder onto iView works as expected, ie it 
> >> generates a catalog and no copy of the original folder is made.
> >> 
> >> It seems as if the Finder is treating the folder as a "stationary pad" 
> >> but, of course, there is no "stationary pad" option for folders or, if 
> >> there is, "Get Info" doesn't show it.
> >> 
> >> Any ideas?
> > 
> > I haven't ever used iView, but I have scripted Finder plenty through the
> > years and haven't ever heard of such Finder behavior. Are you sure it is
> > Finder, and not iView, that is creating the duplicate copy? Isn't it
> > possible that Finder is telling iView to open the folder, and then iView
> > is creating a duplicate and opening that? Have you checked with iView
> > support to see if they might be able to explain this behavior?
> 
> No, I'm sure it's not iView because I can use any other application 
> that accepts a folder dropped on it... even an applescript droplet... 
> and it does the same thing.  And I have found other folders that do the 
> same thing.  All I can figure is that the Finder is treating the folder 
> as a file and checking for where the "stationery" bit would be if it 
> were a file and finding random data.  It must be peculiar to scripting 
> the finder.  Maybe it has something to do with the way I am specifying 
> "nextfolder".  I need to play with it some more.

Do these folders have Folder Actions associated with them?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#70025

On Fri, 20 Feb 2015 11:04:31 -0500, Barry Margolin wrote
(in article <barmar-D783C3.11043120022015@88-209-239-213.giganet.hu>):

> In article <0001HW.D10CB7CD000DA8EAB01029BF@news.astraweb.com>,
>  Nelson <nelson@nowhere.com> wrote:
> 
>> On Fri, 20 Feb 2015 07:49:02 -0500, Jolly Roger wrote
>> (in article <ckoopuFsvveU2@mid.individual.net>):
>> 
>>> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>>>> This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
>>>> images in folders that I want iView MediaPro to generate catalogs for.  
>>>> Because you can't script iView to do this directly, I tell the Finder 
>>>> to open the folder using iView because, if you drop a folder on iView 
>>>> it catalogs it. (repeat: tell application "Finder" to open nextFolder 
>>>> using mediaPro).  Works like a charm... except
>>>> 
>>>> There are two folders out of about 100 where the Finder first makes a 
>>>> copy of the folder and then passes the copy to iView.  I can't see any 
>>>> difference between these folders and all the others.  As far as I can 
>>>> tell all the permissions and ownerships are the same.
>>>> 
>>>> Manually dragging the folder onto iView works as expected, ie it 
>>>> generates a catalog and no copy of the original folder is made.
>>>> 
>>>> It seems as if the Finder is treating the folder as a "stationary pad" 
>>>> but, of course, there is no "stationary pad" option for folders or, if 
>>>> there is, "Get Info" doesn't show it.
>>>> 
>>>> Any ideas?
>>> 
>>> I haven't ever used iView, but I have scripted Finder plenty through the
>>> years and haven't ever heard of such Finder behavior. Are you sure it is
>>> Finder, and not iView, that is creating the duplicate copy? Isn't it
>>> possible that Finder is telling iView to open the folder, and then iView
>>> is creating a duplicate and opening that? Have you checked with iView
>>> support to see if they might be able to explain this behavior?
>> 
>> No, I'm sure it's not iView because I can use any other application 
>> that accepts a folder dropped on it... even an applescript droplet... 
>> and it does the same thing.  And I have found other folders that do the 
>> same thing.  All I can figure is that the Finder is treating the folder 
>> as a file and checking for where the "stationery" bit would be if it 
>> were a file and finding random data.  It must be peculiar to scripting 
>> the finder.  Maybe it has something to do with the way I am specifying 
>> "nextfolder".  I need to play with it some more.
> 
> Do these folders have Folder Actions associated with them?

No, I don't really use folder actions.  And the mystery deepens...

The following script when saved as an application (bundle) displays the 
same behavior when you drop folders on it: the finder copies some 
folders first and then the copy is passed to the app while others are 
passed to the app directly without the finder making a copy.  Very 
strange.

on open (aList) -- Drop Entry
	display dialog "Drop Entry"
	main(aList)
end open


on main(aList)
	display dialog "Main: aList = " & aList as string
end main

on quit
	display dialog "Quitting"
	continue quit
end quit

-- Manual or Run Entry
display dialog "Manual or Run Entry"
main([1, 2, 3])

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70026

On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
> On Fri, 20 Feb 2015 07:49:02 -0500, Jolly Roger wrote
> (in article <ckoopuFsvveU2@mid.individual.net>):
>
>> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>>> This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
>>> images in folders that I want iView MediaPro to generate catalogs for.  
>>> Because you can't script iView to do this directly, I tell the Finder 
>>> to open the folder using iView because, if you drop a folder on iView 
>>> it catalogs it. (repeat: tell application "Finder" to open nextFolder 
>>> using mediaPro).  Works like a charm... except
>>> 
>>> There are two folders out of about 100 where the Finder first makes a 
>>> copy of the folder and then passes the copy to iView.  I can't see any 
>>> difference between these folders and all the others.  As far as I can 
>>> tell all the permissions and ownerships are the same.
>>> 
>>> Manually dragging the folder onto iView works as expected, ie it 
>>> generates a catalog and no copy of the original folder is made.
>>> 
>>> It seems as if the Finder is treating the folder as a "stationary pad" 
>>> but, of course, there is no "stationary pad" option for folders or, if 
>>> there is, "Get Info" doesn't show it.
>>> 
>>> Any ideas?
>> 
>> I haven't ever used iView, but I have scripted Finder plenty through the
>> years and haven't ever heard of such Finder behavior. Are you sure it is
>> Finder, and not iView, that is creating the duplicate copy? Isn't it
>> possible that Finder is telling iView to open the folder, and then iView
>> is creating a duplicate and opening that? Have you checked with iView
>> support to see if they might be able to explain this behavior?
>
> No, I'm sure it's not iView because I can use any other application 
> that accepts a folder dropped on it... even an applescript droplet... 
> and it does the same thing.  And I have found other folders that do the 
> same thing.  All I can figure is that the Finder is treating the folder 
> as a file and checking for where the "stationery" bit would be if it 
> were a file and finding random data.  It must be peculiar to scripting 
> the finder.  Maybe it has something to do with the way I am specifying 
> "nextfolder".  I need to play with it some more.

Very strange. Are the copied folders named "OriginalName copy", or what?

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70028

On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
(in article <ckp9kjF31tdU1@mid.individual.net>):

> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>> On Fri, 20 Feb 2015 07:49:02 -0500, Jolly Roger wrote
>> (in article <ckoopuFsvveU2@mid.individual.net>):
>> 
>>> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>>>> This one has me stumped.  Background: OS 10.6.8.  I have a bunch of 
>>>> images in folders that I want iView MediaPro to generate catalogs for.  
>>>> Because you can't script iView to do this directly, I tell the Finder 
>>>> to open the folder using iView because, if you drop a folder on iView 
>>>> it catalogs it. (repeat: tell application "Finder" to open nextFolder 
>>>> using mediaPro).  Works like a charm... except
>>>> 
>>>> There are two folders out of about 100 where the Finder first makes a 
>>>> copy of the folder and then passes the copy to iView.  I can't see any 
>>>> difference between these folders and all the others.  As far as I can 
>>>> tell all the permissions and ownerships are the same.
>>>> 
>>>> Manually dragging the folder onto iView works as expected, ie it 
>>>> generates a catalog and no copy of the original folder is made.
>>>> 
>>>> It seems as if the Finder is treating the folder as a "stationary pad" 
>>>> but, of course, there is no "stationary pad" option for folders or, if 
>>>> there is, "Get Info" doesn't show it.
>>>> 
>>>> Any ideas?
>>> 
>>> I haven't ever used iView, but I have scripted Finder plenty through the
>>> years and haven't ever heard of such Finder behavior. Are you sure it is
>>> Finder, and not iView, that is creating the duplicate copy? Isn't it
>>> possible that Finder is telling iView to open the folder, and then iView
>>> is creating a duplicate and opening that? Have you checked with iView
>>> support to see if they might be able to explain this behavior?
>> 
>> No, I'm sure it's not iView because I can use any other application 
>> that accepts a folder dropped on it... even an applescript droplet... 
>> and it does the same thing.  And I have found other folders that do the 
>> same thing.  All I can figure is that the Finder is treating the folder 
>> as a file and checking for where the "stationery" bit would be if it 
>> were a file and finding random data.  It must be peculiar to scripting 
>> the finder.  Maybe it has something to do with the way I am specifying 
>> "nextfolder".  I need to play with it some more.
> 
> Very strange. Are the copied folders named "OriginalName copy", or what?

Yes.  It's the identical Finder behavior that you get when opening a 
"stationery pad"  complete with the thermometer display while copying.  
I posted a script upthread which displays the same behavior and doesn't 
even call the Finder but gets the folder name passed in from the 
Finder.  The dialog displays "Folder Copy".  I don't know how to tell 
you to reproduce it because I can't figure out the distinguishing 
characteristics of the folders which cause it to happen :)

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70031

On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
> On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
> (in article <ckp9kjF31tdU1@mid.individual.net>):
>
>> Very strange. Are the copied folders named "OriginalName copy", or what?
>
> Yes.  It's the identical Finder behavior that you get when opening a 
> "stationery pad"  complete with the thermometer display while copying.  
> I posted a script upthread which displays the same behavior and doesn't 
> even call the Finder but gets the folder name passed in from the 
> Finder.  The dialog displays "Folder Copy".  I don't know how to tell 
> you to reproduce it because I can't figure out the distinguishing 
> characteristics of the folders which cause it to happen :)

Yeah. I get that. I take it you have run the "Verify" function of Disk
Utility on the volume in question with no reported errors? What does "ls
-alO" (the O is a capital letter "o") output for the parent directory
containing one of the offending folders?

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70038

On Fri, 20 Feb 2015 15:14:07 -0500, Jolly Roger wrote
(in article <ckpisfF5hnoU1@mid.individual.net>):

> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>> On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
>> (in article <ckp9kjF31tdU1@mid.individual.net>):
>> 
>>> Very strange. Are the copied folders named "OriginalName copy", or what?
>> 
>> Yes.  It's the identical Finder behavior that you get when opening a 
>> "stationery pad"  complete with the thermometer display while copying.  
>> I posted a script upthread which displays the same behavior and doesn't 
>> even call the Finder but gets the folder name passed in from the 
>> Finder.  The dialog displays "Folder Copy".  I don't know how to tell 
>> you to reproduce it because I can't figure out the distinguishing 
>> characteristics of the folders which cause it to happen :)
> 
> Yeah. I get that. I take it you have run the "Verify" function of Disk
> Utility on the volume in question with no reported errors? What does "ls
> -alO" (the O is a capital letter "o") output for the parent directory
> containing one of the offending folders?

Disk checks OK.  There are several different folders on several 
different disks and the script runs natively on two different computers 
with similar results.

On one disk:

drwxr-x---@  91 nel  nel  -           3094 Feb 20 12:41 . (Problem)
drwxr-x---@  54 nel  nel  -           1836 Feb 20 13:00 ..

drwxr-x---  3 nel  nel  -        102 Feb 20 12:35 . (No Problem)
drwxr-xr-x  6 nel  nel  -        204 Feb 20 13:02 ..

On a different disk:

drwxrwxr-x@  12 nel  nel  -           364 Feb 20 13:45 .  (Problem)
drwxr-xr-x  186 nel  nel  -          6280 Feb 20 13:47 ..

drwxrwxr-x    28 nel  nel  -            908 Feb 19 17:50 .  (No 
Problem)
drwxr-xr-x   186 nel  nel  -           6280 Feb 20 13:47 ..

The extended attributes are all com.apple.FinderInfo (whatever that is)

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70039

On Fri, 20 Feb 2015 17:38:01 -0500, Nelson wrote
(in article <0001HW.D10D2179001F47B7B01029BF@news.astraweb.com>):

> On Fri, 20 Feb 2015 15:14:07 -0500, Jolly Roger wrote
> (in article <ckpisfF5hnoU1@mid.individual.net>):
> 
>> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>>> On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
>>> (in article <ckp9kjF31tdU1@mid.individual.net>):
>>> 
>>>> Very strange. Are the copied folders named "OriginalName copy", or what?
>>> 
>>> Yes.  It's the identical Finder behavior that you get when opening a 
>>> "stationery pad"  complete with the thermometer display while copying.  
>>> I posted a script upthread which displays the same behavior and doesn't 
>>> even call the Finder but gets the folder name passed in from the 
>>> Finder.  The dialog displays "Folder Copy".  I don't know how to tell 
>>> you to reproduce it because I can't figure out the distinguishing 
>>> characteristics of the folders which cause it to happen :)
>> 
>> Yeah. I get that. I take it you have run the "Verify" function of Disk
>> Utility on the volume in question with no reported errors? What does "ls
>> -alO" (the O is a capital letter "o") output for the parent directory
>> containing one of the offending folders?
> 
> Disk checks OK.  There are several different folders on several 
> different disks and the script runs natively on two different computers 
> with similar results.
> 
> On one disk:
> 
> drwxr-x---@  91 nel  nel  -           3094 Feb 20 12:41 . (Problem)
> drwxr-x---@  54 nel  nel  -           1836 Feb 20 13:00 ..
> 
> drwxr-x---  3 nel  nel  -        102 Feb 20 12:35 . (No Problem)
> drwxr-xr-x  6 nel  nel  -        204 Feb 20 13:02 ..
> 
> On a different disk:
> 
> drwxrwxr-x@  12 nel  nel  -           364 Feb 20 13:45 .  (Problem)
> drwxr-xr-x  186 nel  nel  -          6280 Feb 20 13:47 ..
> 
> drwxrwxr-x    28 nel  nel  -            908 Feb 19 17:50 .  (No 
> Problem)
> drwxr-xr-x   186 nel  nel  -           6280 Feb 20 13:47 ..
> 
> The extended attributes are all com.apple.FinderInfo (whatever that is)
> 
> 

Well I used xattr to list and then delete the extended attribute:

com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00  
|................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
|................|
00000020

After I deleted it, the folder behaved normally.

Apparently Apple has removed the -c option from xattr so you have to 
know the name of the attribute you are removing and can't just delete 
them whole-scale.

I wonder what that one bit is for.

Somebody tell me again why we need these things?



-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70043

Nelson <nelson@nowhere.com> wrote:

> On Fri, 20 Feb 2015 17:38:01 -0500, Nelson wrote
> (in article <0001HW.D10D2179001F47B7B01029BF@news.astraweb.com>):
> 
> > On Fri, 20 Feb 2015 15:14:07 -0500, Jolly Roger wrote
> > (in article <ckpisfF5hnoU1@mid.individual.net>):
> > 
> >> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
> >>> On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
> >>> (in article <ckp9kjF31tdU1@mid.individual.net>):
> >>> 
> >>>> Very strange. Are the copied folders named "OriginalName copy", or what?
> >>> 
> >>> Yes.  It's the identical Finder behavior that you get when opening a
> >>> "stationery pad"  complete with the thermometer display while copying.
> >>> I posted a script upthread which displays the same behavior and doesn't
> >>> even call the Finder but gets the folder name passed in from the 
> >>> Finder.  The dialog displays "Folder Copy".  I don't know how to tell
> >>> you to reproduce it because I can't figure out the distinguishing
> >>> characteristics of the folders which cause it to happen :)
> >> 
> >> Yeah. I get that. I take it you have run the "Verify" function of Disk
> >> Utility on the volume in question with no reported errors? What does "ls
> >> -alO" (the O is a capital letter "o") output for the parent directory
> >> containing one of the offending folders?
> > 
> > Disk checks OK.  There are several different folders on several 
> > different disks and the script runs natively on two different computers
> > with similar results.
> > 
> > On one disk:
> > 
> > drwxr-x---@  91 nel  nel  -           3094 Feb 20 12:41 . (Problem)
> > drwxr-x---@  54 nel  nel  -           1836 Feb 20 13:00 ..
> > 
> > drwxr-x---  3 nel  nel  -        102 Feb 20 12:35 . (No Problem)
> > drwxr-xr-x  6 nel  nel  -        204 Feb 20 13:02 ..
> > 
> > On a different disk:
> > 
> > drwxrwxr-x@  12 nel  nel  -           364 Feb 20 13:45 .  (Problem)
> > drwxr-xr-x  186 nel  nel  -          6280 Feb 20 13:47 ..
> > 
> > drwxrwxr-x    28 nel  nel  -            908 Feb 19 17:50 .  (No 
> > Problem)
> > drwxr-xr-x   186 nel  nel  -           6280 Feb 20 13:47 ..
> > 
> > The extended attributes are all com.apple.FinderInfo (whatever that is)
> 
> Well I used xattr to list and then delete the extended attribute:
> 
> com.apple.FinderInfo:
> 00000000  00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00  
> |................|
> 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> |................|
> 00000020
> 
> After I deleted it, the folder behaved normally.
> 
> Apparently Apple has removed the -c option from xattr so you have to 
> know the name of the attribute you are removing and can't just delete
> them whole-scale.
> 
> I wonder what that one bit is for.

For a folder, the FinderInfo data structure is a struct FolderInfo (16
bytes) followed by a struct ExtendedFolderInfo (16 bytes). The bit in
question is in the first 16 bytes, so here is that part, from Finder.h:

struct FolderInfo {
  Rect                windowBounds;           /* The position and
dimension of the folder's window */
  UInt16              finderFlags;            /* ex. kIsInvisible,
kNameLocked, etc.*/
  Point               location;               /* Folder's location in
the parent folder */
                                              /* If set to {0, 0}, the
Finder will place the item automatically */
  UInt16              reservedField;          /* (set to 0) */
};

The Rect is the first 8 bytes, so the finderFlags field is 08 00. The
FinderInfo is written in big-endian order (since it was that way dating
all the way back to the original Mac Finder on the 68K family),
therefore it is bit 11 which is set.

According to the defintions in Finder.h, that bit is:

  kIsStationery                 = 0x0800, /* Files only */

(if it was actually the low order byte, that would be bit 3, which is
part of part of kColor field).

Therefore your folder really was flagged as being a stationery item, so
Finder was obeying that flag (even though it is not valid for folders)
and copying the folder when you tried to open it via AppleScript.

How that flag got set is an interesting question. I wonder if any of the
disk repair tools check for it and fix it.

> Somebody tell me again why we need these things?

Some of the Finder Info is still important, e.g. there are flags for
identifying a file as an alias, being invisible or having a custom icon.
I expect icon view still uses the location information, and the
windowBounds is used in some situations.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#70055

On 2015-02-21, David Empson <dempson@actrix.gen.nz> wrote:
> Nelson <nelson@nowhere.com> wrote:
>
>> Well I used xattr to list and then delete the extended attribute:
>> 
>> com.apple.FinderInfo:
>> 00000000  00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00  
>> |................|
>> 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>> |................|
>> 00000020
>> 
>> After I deleted it, the folder behaved normally.
>> 
>> Apparently Apple has removed the -c option from xattr so you have to 
>> know the name of the attribute you are removing and can't just delete
>> them whole-scale.
>> 
>> I wonder what that one bit is for.
>
> For a folder, the FinderInfo data structure is a struct FolderInfo (16
> bytes) followed by a struct ExtendedFolderInfo (16 bytes). The bit in
> question is in the first 16 bytes, so here is that part, from Finder.h:
>
> struct FolderInfo {
>   Rect                windowBounds;           /* The position and
> dimension of the folder's window */
>   UInt16              finderFlags;            /* ex. kIsInvisible,
> kNameLocked, etc.*/
>   Point               location;               /* Folder's location in
> the parent folder */
>                                               /* If set to {0, 0}, the
> Finder will place the item automatically */
>   UInt16              reservedField;          /* (set to 0) */
> };
>
> The Rect is the first 8 bytes, so the finderFlags field is 08 00. The
> FinderInfo is written in big-endian order (since it was that way dating
> all the way back to the original Mac Finder on the 68K family),
> therefore it is bit 11 which is set.
>
> According to the defintions in Finder.h, that bit is:
>
>   kIsStationery                 = 0x0800, /* Files only */
>
> (if it was actually the low order byte, that would be bit 3, which is
> part of part of kColor field).
>
> Therefore your folder really was flagged as being a stationery item, so
> Finder was obeying that flag (even though it is not valid for folders)
> and copying the folder when you tried to open it via AppleScript.

You can use the "mdls" command-line tool to list file metadata, which
includes the kMDItemFSIsStationery flag, if set:

# mdls eBay/
kMDItemContentCreationDate     = 2008-07-11 13:52:18 +0000
kMDItemContentModificationDate = 2008-07-11 13:52:18 +0000
kMDItemContentType             = "public.folder"
kMDItemContentTypeTree         = (
    "public.folder",
    "public.directory",
    "public.item"
)
kMDItemDateAdded               = 2011-10-08 15:04:30 +0000
kMDItemDisplayName             = "eBay"
kMDItemFSContentChangeDate     = 2008-07-11 13:52:18 +0000
kMDItemFSCreationDate          = 2008-07-11 13:52:18 +0000
kMDItemFSCreatorCode           = (null)
kMDItemFSFinderFlags           = 928
kMDItemFSHasCustomIcon         = (null)
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = (null)
kMDItemFSLabel                 = 0
kMDItemFSName                  = "eBay"
kMDItemFSNodeCount             = 6
kMDItemFSOwnerGroupID          = 20
kMDItemFSOwnerUserID           = 502
kMDItemFSSize                  = (null)
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Folder"

> How that flag got set is an interesting question. I wonder if any of the
> disk repair tools check for it and fix it.

It looks like you can toggle it for files with the /usr/bin/SetFile
command-line tool:

# SetFile 
Usage: SetFile [option...] file...
    -a attributes     # attributes (lowercase = 0, uppercase = 1)*
    -c creator        # file creator
    -d date           # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM |
PM]])*
    -m date           # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM
| PM]])*
	-P				  # perform action on symlink
instead of following it
    -t type           # file type

    Note: The following attributes may be used with the -a option:
        A   Alias file
        B   Bundle
        C   Custom icon*
        D   Desktop*
        E   Hidden extension*
        I   Inited*
        M   Shared (can run multiple times)
        N   No INIT resources
        L   Locked
        S   System (name locked)
        T   Stationery
        V   Invisible*
        Z   Busy*

    Note: Items marked with an asterisk (*) are allowed with folders
    Note: Period (.) represents the current date and time.
    Note: [yy]yy < 100 assumes 21st century, e.g. 20yy

Unfortunately, I just tried it on a folder without success...

Were the folders in question created quite a long time ago?

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70064

On Sat, 21 Feb 2015 10:29:32 -0500, Jolly Roger wrote
(in article <ckrmisFl5d6U4@mid.individual.net>):

> On 2015-02-21, David Empson <dempson@actrix.gen.nz> wrote:
>> Nelson <nelson@nowhere.com> wrote:
>> 
>>> Well I used xattr to list and then delete the extended attribute:
>>> 
>>> com.apple.FinderInfo:
>>> 00000000  00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00  
>>>> ................|
>>> 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>>>> ................|
>>> 00000020
>>> 
>>> After I deleted it, the folder behaved normally.
>>> 
>>> Apparently Apple has removed the -c option from xattr so you have to 
>>> know the name of the attribute you are removing and can't just delete
>>> them whole-scale.
>>> 
>>> I wonder what that one bit is for.
>> 
>> For a folder, the FinderInfo data structure is a struct FolderInfo (16
>> bytes) followed by a struct ExtendedFolderInfo (16 bytes). The bit in
>> question is in the first 16 bytes, so here is that part, from Finder.h:
>> 
>> struct FolderInfo {
>> Rect                windowBounds;           /* The position and
>> dimension of the folder's window */
>> UInt16              finderFlags;            /* ex. kIsInvisible,
>> kNameLocked, etc.*/
>> Point               location;               /* Folder's location in
>> the parent folder */
>> /* If set to {0, 0}, the
>> Finder will place the item automatically */
>> UInt16              reservedField;          /* (set to 0) */
>> };
>> 
>> The Rect is the first 8 bytes, so the finderFlags field is 08 00. The
>> FinderInfo is written in big-endian order (since it was that way dating
>> all the way back to the original Mac Finder on the 68K family),
>> therefore it is bit 11 which is set.
>> 
>> According to the defintions in Finder.h, that bit is:
>> 
>> kIsStationery                 = 0x0800, /* Files only */
>> 
>> (if it was actually the low order byte, that would be bit 3, which is
>> part of part of kColor field).
>> 
>> Therefore your folder really was flagged as being a stationery item, so
>> Finder was obeying that flag (even though it is not valid for folders)
>> and copying the folder when you tried to open it via AppleScript.
> 
> You can use the "mdls" command-line tool to list file metadata, which
> includes the kMDItemFSIsStationery flag, if set:
> 
> # mdls eBay/
> kMDItemContentCreationDate     = 2008-07-11 13:52:18 +0000
> kMDItemContentModificationDate = 2008-07-11 13:52:18 +0000
> kMDItemContentType             = "public.folder"
> kMDItemContentTypeTree         = (
>     "public.folder",
>     "public.directory",
>     "public.item"
>> 
> kMDItemDateAdded               = 2011-10-08 15:04:30 +0000
> kMDItemDisplayName             = "eBay"
> kMDItemFSContentChangeDate     = 2008-07-11 13:52:18 +0000
> kMDItemFSCreationDate          = 2008-07-11 13:52:18 +0000
> kMDItemFSCreatorCode           = (null)
> kMDItemFSFinderFlags           = 928
> kMDItemFSHasCustomIcon         = (null)
> kMDItemFSInvisible             = 0
> kMDItemFSIsExtensionHidden     = 0
> kMDItemFSIsStationery          = (null)
> kMDItemFSLabel                 = 0
> kMDItemFSName                  = "eBay"
> kMDItemFSNodeCount             = 6
> kMDItemFSOwnerGroupID          = 20
> kMDItemFSOwnerUserID           = 502
> kMDItemFSSize                  = (null)
> kMDItemFSTypeCode              = ""
> kMDItemKind                    = "Folder"
> 
>> How that flag got set is an interesting question. I wonder if any of the
>> disk repair tools check for it and fix it.
> 
> It looks like you can toggle it for files with the /usr/bin/SetFile
> command-line tool:
> 
> # SetFile 
> Usage: SetFile [option...] file...
>     -a attributes     # attributes (lowercase = 0, uppercase = 1)*
>     -c creator        # file creator
>     -d date           # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM |
> PM]])*
>     -m date           # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM
>> PM]])*
> 	-P				  # perform action on symlink
> instead of following it
>     -t type           # file type
> 
>     Note: The following attributes may be used with the -a option:
>         A   Alias file
>         B   Bundle
>         C   Custom icon*
>         D   Desktop*
>         E   Hidden extension*
>         I   Inited*
>         M   Shared (can run multiple times)
>         N   No INIT resources
>         L   Locked
>         S   System (name locked)
>         T   Stationery
>         V   Invisible*
>         Z   Busy*
> 
>     Note: Items marked with an asterisk (*) are allowed with folders
>     Note: Period (.) represents the current date and time.
>     Note: [yy]yy < 100 assumes 21st century, e.g. 20yy
> 
> Unfortunately, I just tried it on a folder without success...
> 
> Were the folders in question created quite a long time ago?
> 
> 

Thanks Roger & Dave.  I now know more than I care to about Extended 
Attributes :)  The folders in question were created a couple of years 
ago, probably on Snow Leopard (which is where I am today).  Copying one 
of these toxic folders spawns another one.  I am finding more of them 
by trial and error.  Actually, if I hadn't written that script I would 
have probably never noticed it.

I tried to remove all the apple.com.FinderInfo's... whoops!  There went 
all my aliases and labels and who knows what else.  Fortunately I had a 
backup to restore from.  I don't see any quick way to search through my 
drives (I have discovered problem folders on at least two different 
ones) and find just the folders with the stationery bit set and then 
clear it.  I guess I'll just work around it on a case by case basis.

I'm guessing I'm not the only one who has these folders but most people 
just never notice because they don't do anything that triggers the 
problem.  It's probably still around in OS X > 10.6.8.

As far as a utility checking for it, my understanding is that the later 
versions of OS X make much more extensive use of the metadata and 
therefore there will probably be a market for a utility to scan it and 
check for consistency.

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70067

On 2015-02-21, Nelson <nelson@nowhere.com> wrote:
>
> Thanks Roger & Dave.  I now know more than I care to about Extended 
> Attributes :)  The folders in question were created a couple of years 
> ago, probably on Snow Leopard (which is where I am today).  Copying one 
> of these toxic folders spawns another one.  I am finding more of them 
> by trial and error.  Actually, if I hadn't written that script I would 
> have probably never noticed it.

I suspected they were created in previous (buggy) versions of Mac OS X. 

> I tried to remove all the apple.com.FinderInfo's... whoops!  There went 
> all my aliases and labels and who knows what else.  Fortunately I had a 
> backup to restore from.  

Haha! Lucky you had backups. : ) Yeah, you definitely don't want to
delete all of them indiscriminately.

> I don't see any quick way to search through my 
> drives (I have discovered problem folders on at least two different 
> ones) and find just the folders with the stationery bit set and then 
> clear it.  I guess I'll just work around it on a case by case basis.

I think you should be able to use Spotlight to do it. Try this search
out:

mdfind "kMDItemFSIsStationery == 1 && kMDItemKind == 'Folder'"

> I'm guessing I'm not the only one who has these folders but most people 
> just never notice because they don't do anything that triggers the 
> problem.  It's probably still around in OS X > 10.6.8.

I seem to have a bunch of them (according to the Spotlight search above,
at least), but can't seem to duplicate the behavior you are seeing with
your droplet script for some reason. Here's one such folder:

# mdls ~/Desktop/Cracking\ SuperFish/pemcrack-master/bin/mac
kMDItemContentCreationDate     = 2015-02-19 21:12:50 +0000
kMDItemContentModificationDate = 2015-02-19 21:12:50 +0000
kMDItemContentType             = "public.folder"
kMDItemContentTypeTree         = (
    "public.folder",
    "public.directory",
    "public.item"
)
kMDItemDateAdded               = 2015-02-20 15:30:43 +0000
kMDItemDisplayName             = "mac"
kMDItemFSContentChangeDate     = 2015-02-19 21:12:50 +0000
kMDItemFSCreationDate          = 2015-02-19 21:12:50 +0000
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 12
kMDItemFSHasCustomIcon         = (null)
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = 1
kMDItemFSLabel                 = 6
kMDItemFSName                  = "mac"
kMDItemFSNodeCount             = 1
kMDItemFSOwnerGroupID          = 20
kMDItemFSOwnerUserID           = 502
kMDItemFSSize                  = (null)
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Folder"
kMDItemUserTags                = (
    Red
)

Yet when I drop this folder on the droplet script, all that happens is
the "Drop Entry", "Main: aList", and "Quitting" dialogs appear. The
folder does not get duplicated.

Perhaps my mdfind syntax isn't quite right...

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70081

On Sat, 21 Feb 2015 15:35:58 -0500, Jolly Roger wrote
(in article <cks8hdFq318U5@mid.individual.net>):

> I think you should be able to use Spotlight to do it. Try this search
> out:
> 
> mdfind "kMDItemFSIsStationery == 1 && kMDItemKind == 'Folder'"

LOL!  That finds a bunch of them... including my "Documents" folder.  I 
_know_ I didn't create that one.  Sure enough, when I drop it on my 
script app, the finder starts generating a copy of it.

> Perhaps my mdfind syntax isn't quite right...

Or maybe they fixed it in Yosemite?  I am still using Snow Leopard.

-- 
Nelson

[toc] | [prev] | [next] | [standalone]

#70099

On 2015-02-22, Nelson <nelson@nowhere.com> wrote:
> On Sat, 21 Feb 2015 15:35:58 -0500, Jolly Roger wrote
> (in article <cks8hdFq318U5@mid.individual.net>):
>
>> I think you should be able to use Spotlight to do it. Try this search
>> out:
>> 
>> mdfind "kMDItemFSIsStationery == 1 && kMDItemKind == 'Folder'"
>
> LOL!  That finds a bunch of them... including my "Documents" folder.  I 
> _know_ I didn't create that one.  Sure enough, when I drop it on my 
> script app, the finder starts generating a copy of it.
>
>> Perhaps my mdfind syntax isn't quite right...
>
> Or maybe they fixed it in Yosemite?  I am still using Snow Leopard.

Ah. I missed that detail. I suppose it could simply be that Snow Leopard
honors the setting for folders, while Yosemite does not honor it.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70040

On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
> On Fri, 20 Feb 2015 15:14:07 -0500, Jolly Roger wrote
> (in article <ckpisfF5hnoU1@mid.individual.net>):
>
>> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>>> On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
>>> (in article <ckp9kjF31tdU1@mid.individual.net>):
>>> 
>>>> Very strange. Are the copied folders named "OriginalName copy", or what?
>>> 
>>> Yes.  It's the identical Finder behavior that you get when opening a 
>>> "stationery pad"  complete with the thermometer display while copying.  
>>> I posted a script upthread which displays the same behavior and doesn't 
>>> even call the Finder but gets the folder name passed in from the 
>>> Finder.  The dialog displays "Folder Copy".  I don't know how to tell 
>>> you to reproduce it because I can't figure out the distinguishing 
>>> characteristics of the folders which cause it to happen :)
>> 
>> Yeah. I get that. I take it you have run the "Verify" function of Disk
>> Utility on the volume in question with no reported errors? What does "ls
>> -alO" (the O is a capital letter "o") output for the parent directory
>> containing one of the offending folders?
>
> Disk checks OK.  There are several different folders on several 
> different disks and the script runs natively on two different computers 
> with similar results.
>
> On one disk:
>
> drwxr-x---@  91 nel  nel  -           3094 Feb 20 12:41 . (Problem)
> drwxr-x---@  54 nel  nel  -           1836 Feb 20 13:00 ..
>
> drwxr-x---  3 nel  nel  -        102 Feb 20 12:35 . (No Problem)
> drwxr-xr-x  6 nel  nel  -        204 Feb 20 13:02 ..
>
> On a different disk:
>
> drwxrwxr-x@  12 nel  nel  -           364 Feb 20 13:45 .  (Problem)
> drwxr-xr-x  186 nel  nel  -          6280 Feb 20 13:47 ..
>
> drwxrwxr-x    28 nel  nel  -            908 Feb 19 17:50 .  (No 
> Problem)
> drwxr-xr-x   186 nel  nel  -           6280 Feb 20 13:47 ..
>
> The extended attributes are all com.apple.FinderInfo (whatever that is)

I think I would make a backup, and try deleting the com.apple.FinderInfo
with the xattr -c command, to see if that changes anything.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#70041

On Fri, 20 Feb 2015 17:59:05 -0500, Jolly Roger wrote
(in article <ckpshoF7ub6U1@mid.individual.net>):

> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>> On Fri, 20 Feb 2015 15:14:07 -0500, Jolly Roger wrote
>> (in article <ckpisfF5hnoU1@mid.individual.net>):
>> 
>>> On 2015-02-20, Nelson <nelson@nowhere.com> wrote:
>>>> On Fri, 20 Feb 2015 12:36:20 -0500, Jolly Roger wrote
>>>> (in article <ckp9kjF31tdU1@mid.individual.net>):
>>>> 
>>>>> Very strange. Are the copied folders named "OriginalName copy", or what?
>>>> 
>>>> Yes.  It's the identical Finder behavior that you get when opening a 
>>>> "stationery pad"  complete with the thermometer display while copying.  
>>>> I posted a script upthread which displays the same behavior and doesn't 
>>>> even call the Finder but gets the folder name passed in from the 
>>>> Finder.  The dialog displays "Folder Copy".  I don't know how to tell 
>>>> you to reproduce it because I can't figure out the distinguishing 
>>>> characteristics of the folders which cause it to happen :)
>>> 
>>> Yeah. I get that. I take it you have run the "Verify" function of Disk
>>> Utility on the volume in question with no reported errors? What does "ls
>>> -alO" (the O is a capital letter "o") output for the parent directory
>>> containing one of the offending folders?
>> 
>> Disk checks OK.  There are several different folders on several 
>> different disks and the script runs natively on two different computers 
>> with similar results.
>> 
>> On one disk:
>> 
>> drwxr-x---@  91 nel  nel  -           3094 Feb 20 12:41 . (Problem)
>> drwxr-x---@  54 nel  nel  -           1836 Feb 20 13:00 ..
>> 
>> drwxr-x---  3 nel  nel  -        102 Feb 20 12:35 . (No Problem)
>> drwxr-xr-x  6 nel  nel  -        204 Feb 20 13:02 ..
>> 
>> On a different disk:
>> 
>> drwxrwxr-x@  12 nel  nel  -           364 Feb 20 13:45 .  (Problem)
>> drwxr-xr-x  186 nel  nel  -          6280 Feb 20 13:47 ..
>> 
>> drwxrwxr-x    28 nel  nel  -            908 Feb 19 17:50 .  (No 
>> Problem)
>> drwxr-xr-x   186 nel  nel  -           6280 Feb 20 13:47 ..
>> 
>> The extended attributes are all com.apple.FinderInfo (whatever that is)
> 
> I think I would make a backup, and try deleting the com.apple.FinderInfo
> with the xattr -c command, to see if that changes anything.
> 
> 

Unfortunately, they removed -c from Snow Leopard.  -dr works but you 
can only remove one attribute at a time.

-- 
Nelson

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.mac.system

csiph-web