Apple security guidelines - need to hide files in unfriendly places?

[Bread]

So I came across the following, in explanation of why MacFamilyTree
from Synium software has made a very unfriendly change to where they
store my files.

In previous versions, I was able to leave the files anywhere -- and in
fact, left my MFT data file in Dropbox for obvious reasons.

Obviously, there is room for interpretation of some of these
guidelines. Not all apps are hiding our datafiles from us, not even
Apple's apps. Can anyone here shed light on why MFT has decided to
interpret the guidelines this way?

This is all aside from the fact that the just-released v7 is now an App
Store only version, which may be subject to more strict guidelines and
perhaps they made the 6.3 changes in prep for that, but nevertheless,
it's not like Pages or Numbers or, well, any of a zillion other apps
require my files to be hidden in annoying places.

[fwiw, they stick the file in
~/Library/Containers/com.synium.macfamilytree/Data/Documents ]



> I work on a database together with other persons. Is it possible to
> save my MacFamilyTree 6.3 database in a Dropbox folder?
>
> MacFamilyTree 6.3 has been adopted to Apple‘s new security guidelines.
> According to these guidelines, the apps and all relating files must be
> separated from critical system components and other applications.
> Unfortunately it is no longer possible to save the database in a custom
> location.
> If you would like to make a backup of your current database or save a
> copy of your database in another location, it is possible to export the
> database. To save a copy of the current database in a custom location,
> just go to the top menu bar and select:
> "File" -> "Export MacFamilyTree Database"
> We are aware of the fact, that the new file management does bring some
> problems, especially for users who synchronize their files with a cloud
> service like Dropbox. We are currently planning to implement iCloud.
> For obvious reasons, the iCloud implementation has highest priority, it
> will probably implemented in a future version of MacFamilyTree, which
> is scheduled for this summer.
> We sincerely apologize for the inconvenience.

[Tom Stiller]

In article <ksvk7l$dbs$1...@reader1.panix.com>,

Bread <BreadW...@Fractious.net> wrote:

> So I came across the following, in explanation of why MacFamilyTree
> from Synium software has made a very unfriendly change to where they
> store my files.
>
> In previous versions, I was able to leave the files anywhere -- and in
> fact, left my MFT data file in Dropbox for obvious reasons.
>
> Obviously, there is room for interpretation of some of these
> guidelines. Not all apps are hiding our datafiles from us, not even
> Apple's apps. Can anyone here shed light on why MFT has decided to
> interpret the guidelines this way?
>
> This is all aside from the fact that the just-released v7 is now an App
> Store only version, which may be subject to more strict guidelines and
> perhaps they made the 6.3 changes in prep for that, but nevertheless,
> it's not like Pages or Numbers or, well, any of a zillion other apps
> require my files to be hidden in annoying places.
>
> [fwiw, they stick the file in
> ~/Library/Containers/com.synium.macfamilytree/Data/Documents ]
>
>
>

> > MacFamilyTree 6.3 has been adopted to Apple‘s new security guidelines.
> > According to these guidelines, the apps and all relating files must be
> > separated from critical system components and other applications.
> > Unfortunately it is no longer possible to save the database in a custom
> > location.

There in nothing in the above guideline that would preclude storing a
data file in the Dropbox folder which is contained in the user's Home
folder and well away from any "critical system components and other
applications".

MFT programmers need a lesson in reading for comprehension.

--
PRAY, v. To ask that the laws of the universe be annulled in behalf
of a single petitioner confessedly unworthy. -- Ambrose Bierce

[Kevin McMurtrie]

In article <ksvk7l$dbs$1...@reader1.panix.com>,
Bread <BreadW...@Fractious.net> wrote:

Yes, Apple really is that screwed up. iCloud and other new APIS require
apps to be signed and run in the new dumbed-down sandbox security model.

Apple has been wanting to eliminate visible filesystems for a long time.
It started with iPhoto and iTunes/iPod obfuscating the filesystem. iOS
was the first Apple product to forbid it. "Lion" started the MacOS
enforcement. It hides the Library directories and it requires apps to
be signed and sandboxed to be available in the Apple store or use new
APIs. iCloud is also not a hierarchical filesystem so it doesn't
resemble anything a user can directly interact with.

There's a simple solution: Stop rewarding stupid design changes with
money. Don't buy it.

<https://developer.apple.com/library/ios/#documentation/General/Conceptua
l/iCloudDesignGuide/Chapters/DesigningForDocumentsIniCloud.html#//apple_r
ef/doc/uid/TP40012094-CH2-SW1>

<http://developer.apple.com/library/mac/#documentation/Security/Conceptua
l/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html>
--
I will not see posts from Google because I must filter them as spam

[Paul Sture]

In article <ksvk7l$dbs$1...@reader1.panix.com>,
Bread <BreadW...@Fractious.net> wrote:

> So I came across the following, in explanation of why MacFamilyTree
> from Synium software has made a very unfriendly change to where they
> store my files.
>
> In previous versions, I was able to leave the files anywhere -- and in
> fact, left my MFT data file in Dropbox for obvious reasons.
>
> Obviously, there is room for interpretation of some of these
> guidelines. Not all apps are hiding our datafiles from us, not even
> Apple's apps. Can anyone here shed light on why MFT has decided to
> interpret the guidelines this way?
>
> This is all aside from the fact that the just-released v7 is now an App
> Store only version, which may be subject to more strict guidelines and
> perhaps they made the 6.3 changes in prep for that, but nevertheless,
> it's not like Pages or Numbers or, well, any of a zillion other apps
> require my files to be hidden in annoying places.
>
> [fwiw, they stick the file in
> ~/Library/Containers/com.synium.macfamilytree/Data/Documents ]

This sounds as though they misinterpreted the guidelines.

I don't think that Spotlight searches ~/Library for example*, so how on
earth can your data be available to that?

* I couldn't find the BBEDit User Manual when I lasted used Spotlight to
look for it; it is well and truly buried somewhere. The Help menu very
unhelpfully tried to download it for me, but my internet connection was
well and truly broken, so I couldn't find the thing.

Ah, it's here:

/Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf

>
> > I work on a database together with other persons. Is it possible to
> > save my MacFamilyTree 6.3 database in a Dropbox folder?
> >
> > MacFamilyTree 6.3 has been adopted to Apple‘s new security guidelines.
> > According to these guidelines, the apps and all relating files must be
> > separated from critical system components and other applications.
> > Unfortunately it is no longer possible to save the database in a custom
> > location.
> > If you would like to make a backup of your current database or save a
> > copy of your database in another location, it is possible to export the
> > database. To save a copy of the current database in a custom location,
> > just go to the top menu bar and select:
> > "File" -> "Export MacFamilyTree Database"
> > We are aware of the fact, that the new file management does bring some
> > problems, especially for users who synchronize their files with a cloud
> > service like Dropbox. We are currently planning to implement iCloud.
> > For obvious reasons, the iCloud implementation has highest priority, it
> > will probably implemented in a future version of MacFamilyTree, which
> > is scheduled for this summer.
> > We sincerely apologize for the inconvenience.

--
Paul Sture

[dorayme]

In article <nospam-43FC8B....@news.chingola.ch>,

Paul Sture <nos...@sture.ch> wrote:

> I don't think that Spotlight searches ~/Library for example*, so how on
> earth can your data be available to that?
>
> * I couldn't find the BBEDit User Manual when I lasted used Spotlight to
> look for it; it is well and truly buried somewhere. The Help menu very
> unhelpfully tried to download it for me, but my internet connection was
> well and truly broken, so I couldn't find the thing.
>
> Ah, it's here:
>
> /Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf

In my BBEdit (an older one, 8) it is a direct help menu item. And
where it resides is in the app's Applications package Contents under
resources. But Spotlight fails to find it.

In EasyFind, which I turn to at the slightest resistance from
Spotlight, there is a helpful set of parameters on the left of the
find panel and one of these is Include Package Contents (as well as
Invisible Files & Folders). Finds it quickly then! Spotlight settings
under Sys Prefs have parameters too, but not the useful one about
Package Contents.

--
dorayme

[bi...@mix.com]

Lewis <g.k...@gmail.com.dontsendmecopies> writes:

> There has been no elimination of the Filesystem in OS X, only the
> obfuscation of it to keep most people from ever having to use it.

Since said filesystem is still there, I'd guess a symbolic link
would solve the OP's problem.

Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number

[Kevin McMurtrie]

In article <slrnkv83av....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:

> In message <51f3f72b$0$52824$742e...@news.sonic.net>

> No.

>
> > iCloud and other new APIS require
> > apps to be signed and run in the new dumbed-down sandbox security model.
>

> Which does not require files to be stored in the Containers. I have
> plenty of apps from the MAS that do not require storing files in the
> Container folder. Let's see, The Unarchiver, BBedit, 1Password, iMovie,
> iPhoto, XChat Azure, WriteRoom, Evernote, Skitch, and TextWrangler.

>
> > Apple has been wanting to eliminate visible filesystems for a long time.
>

> For the vast majority of users, this is the best thing.

>
> There has been no elimination of the Filesystem in OS X, only the
> obfuscation of it to keep most people from ever having to use it.

That should read, "for the vast majority of remaining Apple users." My
next computer is not Apple. Nobody uses the no-filesystem design
because it has well known shortcomings. The filesystem is a GUI to help
the user. Anyone using computers for a while knows that there used to
be "Mac" files, "Windows" files, "DOS" files, and "Unix" files that were
not compatible unless run through a laborious export/import process.
What Apple is moving to is the extreme extension of that old problem.
Data will belong to only ONE application and ONE storage system. Apple
may, at their choosing, revoke the authorization token for that ONE
application or ONE storage system that contains your data. Kiss your
digital belongings goodbye.

Maybe you should read Apple's new developer docs. Switching to
Objective C and XCode a decade ago was Apple's first "fuck you" to
developers. The whole thing is hideous and crude compared to other
development environments. That's when I dumped MacOS development. The
new stuff, software and hardware, is pure megalomaniacal greed. Like
any big corporation racing towards failure, Apple knows where the money
comes from but has completely forgotten why.

[Wes Groleau]

On 07-27-2013 01:01, Bread wrote:
>> MacFamilyTree 6.3 has been adopted to Apple‘s new security guidelines.
>> According to these guidelines, the apps and all relating files must be
>> separated from critical system components and other applications.
>> Unfortunately it is no longer possible to save the database in a
>> custom location.
>> If you would like to make a backup of your current database or save a
>> copy of your database in another location, it is possible to export
>> the database. To save a copy of the current database in a custom
>> location, just go to the top menu bar and select:
>> "File" -> "Export MacFamilyTree Database"
>> We are aware of the fact, that the new file management does bring some
>> problems, especially for users who synchronize their files with a
>> cloud service like Dropbox. We are currently planning to implement
>> iCloud. For obvious reasons, the iCloud implementation has highest
>> priority, it will probably implemented in a future version of
>> MacFamilyTree, which is scheduled for this summer.
>> We sincerely apologize for the inconvenience.

Translation:
"We want to make an iPad version, and we're not willing to make two
different versions. So all versions will have whatever restrictions IOS
imposes on us."

Disclaimer:
I am not fluent in Weasel, so I may have mistranslated.
In fact, it's possible it's not Weasel at all.

--
Wes Groleau

“There are more people worthy of blame
than there is blame to go around."

[Wes Groleau]

On 07-27-2013 01:01, Bread wrote:

> [fwiw, they stick the file in
> ~/Library/Containers/com.synium.macfamilytree/Data/Documents ]

Assuming you want to keep using MFT instead of a better program :-)

and assuming your Dropbox folder is on the same disk partition as your
home folder, try the following:

On ONE machine, make sure MFT is not running.

Then open Terminal and type

mv ~/Library/Containers/com.synium.macfamilytree/Data/Documents \

Hit return after the backslash WITHOUT A SPACE AFTER IT.

Use Finder to locate the Dropbox folder you want it in.

Drag that folder's icon to the Terminal window. The full path will appear.

Click in the the Terminal window and press Return.

Open the Dropbox folder you selected. You will see the folder there
named "Documents" Rename it to MFT or whatever else will ensure you'll
always know what it is.

Back in the Terminal window, type

ln -s

(leave a space after the 's' and don't hit return)

Drag the icon of the folder you just renamed into the Terminal window.

make sure there is a space after its name, then paste in
~/Library/Containers/com.synium.macfamilytree/Data
and press return.

Now, the real thing is in Dropbox, but MFT will think it is in
~/Library/Containers/com.synium.macfamilytree/DataNow there is a remote
possibility the developers will have added code to detect this trick and
punish you. But I doubt they're willing to work that hard if they even
know how.

If it doesn't work, shut down MFT and undo it all. If you're not sure
how, post here and someone will help.

Don't do any of it with MFT running.

NOW, after making sure it works, on all other machines, it is slightly
different:

Shut down MFT

rm -rf ~/Library/Containers/com.synium.macfamilytree/Data/Documents

(this _removes_ the whole thing, but don't worry, we are going to
play the same trick on MFT)

in the Terminal window, type

ln -s

(leave a space after the 's' and don't hit return)

Use Finder to go into Dropbox until you see MFT or whatever you called
it. Drag its icon into Terminal.

make sure there is a space after its name, then paste in
~/Library/Containers/com.synium.macfamilytree/Data
and press return.

Since you asked in the Mac group, I posted Mac instructions. You can
have the same effect in Windows, only the details of making it happen
are different.

Same for Unic/BSD/Solaris/Linux/etc.

However, it won't work on IOS, and if you "export to Dropbox" on any
machine, you'll probably break it. But you won't need to, since we
fooled the system into using the copy in DropBox.

[Wes Groleau]

On 07-27-2013 19:57, Kevin McMurtrie wrote:
> That should read, "for the vast majority of remaining Apple users." My
> next computer is not Apple. Nobody uses the no-filesystem design
> because it has well known shortcomings. The filesystem is a GUI to help
> the user.

No, the Finder is a GUI to help the user with the filesystem.

So far, I have no problem with the Mac filesystem.

But I am starting to suspect Apple is willing to drive away a million of
us geeks in order to lure five million non-geeks away from Microsoft.

And to prevent them from succeeding, Microsoft is trying to do the same
thing.

Should they go far enough to change my suspicion into certainty, then I
will happily cooperate and dump them for some other Unix or similar.

Either that or become Amish.

[Wes Groleau]

On 07-27-2013 11:54, Paul Sture wrote:
> Ah, it's here:
>
> /Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf

Are you sure it isn't
~/Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf
?

Whichever path it is,

ln -s "path" ~/Desktop/App_Support

[Kevin McMurtrie]

In article <kt1lcq$9de$1...@reader1.panix.com>, bi...@MIX.COM wrote:

> Lewis <g.k...@gmail.com.dontsendmecopies> writes:
>
> > There has been no elimination of the Filesystem in OS X, only the
> > obfuscation of it to keep most people from ever having to use it.
>
> Since said filesystem is still there, I'd guess a symbolic link
> would solve the OP's problem.
>
> Billy Y..

Has anyone gotten that to work? I suspect that a symlink won't fool the
security barrier. (I will not buy any sandboxed apps so I can't try it.)

[Bread]

On 2013-07-27 13:47:16 +0000, Tom Stiller said:

> In article <ksvk7l$dbs$1...@reader1.panix.com>,
> Bread <BreadW...@Fractious.net> wrote:
>
>> So I came across the following, in explanation of why MacFamilyTree
>> from Synium software has made a very unfriendly change to where they
>> store my files.
>>

>> [fwiw, they stick the file in
>> ~/Library/Containers/com.synium.macfamilytree/Data/Documents ]
>>
>

> There in nothing in the above guideline that would preclude storing a
> data file in the Dropbox folder which is contained in the user's Home
> folder and well away from any "critical system components and other
> applications".
>
> MFT programmers need a lesson in reading for comprehension.

That's what I thought.

Obviously there's nothing requiring apps which are signed, secure, and
live in the App Store to be prohibited from storing their data files in
places other than such hidden locations. If that were the case, Pages
and Numbers would be pretty freaking useless.

I was just wondering if there was something here more subtle that I'd missed.

Sigh.

Thanks.

[Bread]

On 2013-07-27 23:33:46 +0000, bi...@MIX.COM said:

> Lewis <g.k...@gmail.com.dontsendmecopies> writes:
>
>> There has been no elimination of the Filesystem in OS X, only the
>> obfuscation of it to keep most people from ever having to use it.
>
> Since said filesystem is still there, I'd guess a symbolic link
> would solve the OP's problem.

My experience with other apps suggests not. I'll give it a try with
this one, though.

Thanks.

[Bread]

On 2013-07-28 04:40:41 +0000, Wes Groleau said:

> On 07-27-2013 19:57, Kevin McMurtrie wrote:
>> That should read, "for the vast majority of remaining Apple users." My
>> next computer is not Apple. Nobody uses the no-filesystem design
>> because it has well known shortcomings. The filesystem is a GUI to help
>> the user.
>
> No, the Finder is a GUI to help the user with the filesystem.
>
> So far, I have no problem with the Mac filesystem.

I have no problem with the filesystem, either. And the beauty of
Dropbox is that it works *with* the filesystem rather than instead of
it the way iCloud does.

My problem is with a developer who seems to be interpreting Apple's
guidelines in ways that others don't seem to be doing, (where others
includes Apple themselves). I just want to make sure I'm not missing
something here before I bitch at the developer. I'm sure I'm not the
only one who's complained to them, though, since they took the trouble
to write that bizarre FAQ wherein they are trying to blame Apple on
their annoying design decision.

> But I am starting to suspect Apple is willing to drive away a million
> of us geeks in order to lure five million non-geeks away from Microsoft.

Documents in the Cloud via iCloud, with its iOS-like application/data
silos is a surefire way to keep anyone doing serious professional
multi-application work away. Forcing it as the only way to sync
something (ie. what MFT is doing) is certainly driving me away from
their app. And if Apple broke Pages and Numbers so I couldn't sync my
work between my machines via Dropbox and/or SpiderOak, I'd drop both of
them and go back to Microsoft and/or LibreOffice in a second.

Unfortunately, I really do like MFT. And it was entirely accidental -
I'd never had any interest in such software, but an older version came
in a software bundle I'd bought and I just got sucked right into it.

> Should they go far enough to change my suspicion into certainty, then I
> will happily cooperate and dump them for some other Unix or similar.
>
> Either that or become Amish.

Heard that.

[Bread]

On 2013-07-27 22:53:01 +0000, dorayme said:

> In article <nospam-43FC8B....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
>> I don't think that Spotlight searches ~/Library for example*, so how on
>> earth can your data be available to that?
>

> In EasyFind, which I turn to at the slightest resistance from
> Spotlight, there is a helpful set of parameters on the left of the
> find panel and one of these is Include Package Contents (as well as
> Invisible Files & Folders). Finds it quickly then! Spotlight settings
> under Sys Prefs have parameters too, but not the useful one about
> Package Contents.

To pick nits on Paul, Spotlight does search/index ~/Library. But the
dumbed-down interface that Apple puts up on the top right of the screen
doesn't take advantage of it.

And a huge thumbs-up for EasyFind. In fact, EasyFind is how I found
that stupid hidden MacFamilyTree file.

[Paul Sture]

In article <kt2770$v8d$1...@dont-email.me>,

Wes Groleau <Grolea...@FreeShell.org> wrote:

> On 07-27-2013 11:54, Paul Sture wrote:
> > Ah, it's here:
> >
> > /Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf
>
> Are you sure it isn't
> ~/Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf
> ?

Yeah, I noticed that after posting. MT-NW sometimes chews the tilde.

>
> Whichever path it is,
>
> ln -s "path" ~/Desktop/App_Support

That's a good idea.

What was really annoying was that I had a couple of previous versions of
the manual there but couldn't find them.

It appears that after a BBEdit upgrade, Help -> User Manual can point to
a new version of the manual and wants to download that if not present.

I currently have these versions in the aforementioned path:

BBEdit User Manual (10.5).pdf
BBEdit User Manual (10.5.2).pdf
BBEdit User Manual (10.5.5).pdf

I think it's a ludicrous situation when you can't find the user manual
after an upgrade.

--
Paul Sture

[Paul Sture]

In article <slrnkv95hr....@mgb.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:

> In message <nospam-43FC8B....@news.chingola.ch>

> Paul Sture <nos...@sture.ch> wrote:
> > In article <ksvk7l$dbs$1...@reader1.panix.com>,
> > Bread <BreadW...@Fractious.net> wrote:
> > * I couldn't find the BBEDit User Manual when I lasted used Spotlight to
> > look for it; it is well and truly buried somewhere. The Help menu very
> > unhelpfully tried to download it for me, but my internet connection was
> > well and truly broken, so I couldn't find the thing.
>

> The BBEdit manual was included in the app, I thought, and copied out
> when you first accessed it.

Not so with version 10.5.5, although this is the App Store version.

--
Paul Sture

[Paul Sture]

In article <dorayme-9DABC6...@news.albasani.net>,

dorayme <dor...@optusnet.com.au> wrote:

> In article <nospam-43FC8B....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
> > I don't think that Spotlight searches ~/Library for example*, so how on
> > earth can your data be available to that?
> >
> > * I couldn't find the BBEDit User Manual when I lasted used Spotlight to
> > look for it; it is well and truly buried somewhere. The Help menu very
> > unhelpfully tried to download it for me, but my internet connection was
> > well and truly broken, so I couldn't find the thing.
> >
> > Ah, it's here:
> >
> > /Library/Application Support/BBEdit/BBEdit User Manual (10.5.5).pdf
>
> In my BBEdit (an older one, 8) it is a direct help menu item. And
> where it resides is in the app's Applications package Contents under
> resources. But Spotlight fails to find it.

I've just looked in mine (10.5.5) and it's not there.

> In EasyFind, which I turn to at the slightest resistance from
> Spotlight, there is a helpful set of parameters on the left of the
> find panel and one of these is Include Package Contents (as well as
> Invisible Files & Folders). Finds it quickly then! Spotlight settings
> under Sys Prefs have parameters too, but not the useful one about
> Package Contents.

Ah, I just tried NotLight instead of Spotlight and got the ones in
Application Support in an instant!

NotLight my ba an old program but I'm keeping it around!

--
Paul Sture

[Paul Sture]

In article <kt2e4l$63o$1...@reader1.panix.com>,

Bread <BreadW...@Fractious.net> wrote:

> On 2013-07-27 22:53:01 +0000, dorayme said:
>
> > In article <nospam-43FC8B....@news.chingola.ch>,
> > Paul Sture <nos...@sture.ch> wrote:
> >
> >> I don't think that Spotlight searches ~/Library for example*, so how on
> >> earth can your data be available to that?
> >
> > In EasyFind, which I turn to at the slightest resistance from
> > Spotlight, there is a helpful set of parameters on the left of the
> > find panel and one of these is Include Package Contents (as well as
> > Invisible Files & Folders). Finds it quickly then! Spotlight settings
> > under Sys Prefs have parameters too, but not the useful one about
> > Package Contents.
>
> To pick nits on Paul, Spotlight does search/index ~/Library. But the
> dumbed-down interface that Apple puts up on the top right of the screen
> doesn't take advantage of it.

Well I did prefix it with "I don't think" rather than making an outright
assertion :_)

NotLight got it as well. That dumbed down Spotlight interface is to blame.

> And a huge thumbs-up for EasyFind. In fact, EasyFind is how I found
> that stupid hidden MacFamilyTree file.

I have just downloaded EasyFind and will add it to my arsenal.
Thanks to you and dorayme for mentioning it.

--
Paul Sture

[Doc O'Leary]

In article <51f45e5e$0$52800$742e...@news.sonic.net>,

Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:

> Nobody uses the no-filesystem design
> because it has well known shortcomings. The filesystem is a GUI to help
> the user.

Uh, no. A filesystem was a way to organize data that made it easier for
ancient computers to organize data. They existed long before GUIs.
They have well-known shortcomings of their own (e.g., files cannot be in
two different locations in the hierarchy at the same time).

> Anyone using computers for a while knows that there used to
> be "Mac" files, "Windows" files, "DOS" files, and "Unix" files that were
> not compatible unless run through a laborious export/import process.

That had to do with data formats, not filesystems. You seem to have
very little technical understanding.

> Data will belong to only ONE application and ONE storage system. Apple
> may, at their choosing, revoke the authorization token for that ONE
> application or ONE storage system that contains your data. Kiss your
> digital belongings goodbye.

This, I agree, is very much wrong. It's part of why I don't put my Mac
software in the App Store.

> Switching to
> Objective C and XCode a decade ago was Apple's first "fuck you" to
> developers. The whole thing is hideous and crude compared to other
> development environments.

You clearly know nothing about development, either now or back when the
mess that was Mac OS 7-9 development was inflicted on us. Objective-C
offered, and still offers, more *useful* features than the alternatives.
I happily cheer categories instead of cursing C++'s templates or Java's
finalized classes. The Foundation framework has been a workhorse from
NeXT to iOS, essentially unchanged for decades.

> The
> new stuff, software and hardware, is pure megalomaniacal greed. Like
> any big corporation racing towards failure, Apple knows where the money
> comes from but has completely forgotten why.

Well . . . bye.

--
iPhone apps that matter: http://appstore.subsume.com/
My personal UDP list: 127.0.0.1, localhost, googlegroups.com, theremailer.net,
and probably your server, too.

[Tom Stiller]

In article <droleary-8A9656...@news.eternal-september.org>,

Doc O'Leary <drol...@1usenet2013.subsume.com> wrote:

> In article <51f45e5e$0$52800$742e...@news.sonic.net>,
> Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:
>
> > Nobody uses the no-filesystem design
> > because it has well known shortcomings. The filesystem is a GUI to help
> > the user.
>
> Uh, no. A filesystem was a way to organize data that made it easier for
> ancient computers to organize data. They existed long before GUIs.
> They have well-known shortcomings of their own (e.g., files cannot be in
> two different locations in the hierarchy at the same time).

Isn't that what a hard link accomplishes?

[Wes Groleau]

On 07-28-2013 12:16, Doc O'Leary wrote:
> They have well-known shortcomings of their own (e.g., files cannot be in
> two different locations in the hierarchy at the same time).

Until hard-links were invented.

But I agree. I'd like to keep important things in a database where all
sorts of metadata can be added as columns, and SQL (or something else)
lets you organize it in as many ways as you want.

--
Wes Groleau

“To know what you prefer, instead of humbly saying
Amen to what the world tells you you should prefer,
is to have kept your soul alive.”
— Robert Louis Stevenson

[Kevin McMurtrie]

In article <slrnkvbeu3...@mgb.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:

> In message <droleary-8A9656...@news.eternal-september.org>

> Doc O'Leary <drol...@1usenet2013.subsume.com> wrote:

> > In article <51f45e5e$0$52800$742e...@news.sonic.net>,
> > Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:
>
> >> Nobody uses the no-filesystem design
> >> because it has well known shortcomings. The filesystem is a GUI to help
> >> the user.
>
> > Uh, no. A filesystem was a way to organize data that made it easier for
> > ancient computers to organize data. They existed long before GUIs.
> > They have well-known shortcomings of their own (e.g., files cannot be in
> > two different locations in the hierarchy at the same time).
>

> Under UNIX they can be.
>
> $ ls -ls /bin/csh
> 696 -rwxr-xr-x 2 root wheel 772992 Mar 22 21:01 /bin/csh
> $ ls -ls /bin/tcsh
> 696 -rwxr-xr-x 2 root wheel 772992 Mar 22 21:01 /bin/tcsh
> $ diff /bin/csh /bin/tcsh
> $
>
> One file in two locations.

>
> >> Switching to
> >> Objective C and XCode a decade ago was Apple's first "fuck you" to
> >> developers. The whole thing is hideous and crude compared to other
> >> development environments.
>
> > You clearly know nothing about development,
>

> No kidding. anyone talking smack about Obj-C is an ignorant idiot. Obj-C
> is the *best* C avaliable, without a doubt. There is no other C even in
> the same league.

Objective-C attempts to solve obsolete problems in an inelegant way.
The syntax is a clusterfuck of unreadability and compilers have trouble
optimizing the messaging system used to implement virtual methods. You
should take a look at other modern languages, including C++11.

XCode is a just a text editor with a search engine and some hooks into
aging unix tools. It knows almost nothing about the meaning of code or
the context in which you're typing. I used IDEs in 1989 that were
smarter. If I launch XCode now, it's because something corrupted
Apple's brain-dead mapping of mime types to apps.

> > either now or back when the mess that was Mac OS 7-9 development was
> > inflicted on us. Objective-C offered, and still offers, more *useful*
> > features than the alternatives. I happily cheer categories instead of
> > cursing C++'s templates or Java's finalized classes. The Foundation
> > framework has been a workhorse from NeXT to iOS, essentially unchanged
> > for decades.

[Doc O'Leary]

In article <tom_stiller-0BFB...@news.individual.net>,

Tom Stiller <tom_s...@yahoo.com> wrote:

> In article <droleary-8A9656...@news.eternal-september.org>,
> Doc O'Leary <drol...@1usenet2013.subsume.com> wrote:
>
> > In article <51f45e5e$0$52800$742e...@news.sonic.net>,
> > Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:
> >
> > > Nobody uses the no-filesystem design
> > > because it has well known shortcomings. The filesystem is a GUI to help
> > > the user.
> >
> > Uh, no. A filesystem was a way to organize data that made it easier for
> > ancient computers to organize data. They existed long before GUIs.
> > They have well-known shortcomings of their own (e.g., files cannot be in
> > two different locations in the hierarchy at the same time).
>
> Isn't that what a hard link accomplishes?

Only on a local filesystem, which isn't necessarily what the hierarchy
represents. It also creates what amounts to a new file/node in the
filesystem, rather than representing a unique file in multiple
locations. Like symbolic links and aliases, it's a handy hack that
works around the filesystem's limitations, but it generally doesn't
reflect how the user *actually* wants to manage the data.

[Doc O'Leary]

In article <slrnkvbeu3...@mgb.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:

> In message <droleary-8A9656...@news.eternal-september.org>

> Doc O'Leary <drol...@1usenet2013.subsume.com> wrote:

> > In article <51f45e5e$0$52800$742e...@news.sonic.net>,
> > Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:
>
> >> Nobody uses the no-filesystem design
> >> because it has well known shortcomings. The filesystem is a GUI to help
> >> the user.
>
> > Uh, no. A filesystem was a way to organize data that made it easier for
> > ancient computers to organize data. They existed long before GUIs.
> > They have well-known shortcomings of their own (e.g., files cannot be in
> > two different locations in the hierarchy at the same time).
>

> Under UNIX they can be.
>
> $ ls -ls /bin/csh
> 696 -rwxr-xr-x 2 root wheel 772992 Mar 22 21:01 /bin/csh
> $ ls -ls /bin/tcsh
> 696 -rwxr-xr-x 2 root wheel 772992 Mar 22 21:01 /bin/tcsh
> $ diff /bin/csh /bin/tcsh
> $
>
> One file in two locations.

What is the one command to delete that "one file"? What is the command
to also have it's location on a thumb drive or a network share? Yes,
for *a* filesystem you have some handy hacks that kinda, almost work
well. But from an end user standpoint, OSes have been really slow to
develop meta managers that better reflect how data is used in practice
these days. Sandboxing only makes the shortcomings of simple
filesystems worse.

[Tom Stiller]

In article <droleary-DE8DDD...@news.eternal-september.org>,

Doc O'Leary <drol...@1usenet2013.subsume.com> wrote:

> In article <tom_stiller-0BFB...@news.individual.net>,
> Tom Stiller <tom_s...@yahoo.com> wrote:
>
> > In article <droleary-8A9656...@news.eternal-september.org>,
> > Doc O'Leary <drol...@1usenet2013.subsume.com> wrote:
> >
> > > In article <51f45e5e$0$52800$742e...@news.sonic.net>,
> > > Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:
> > >
> > > > Nobody uses the no-filesystem design
> > > > because it has well known shortcomings. The filesystem is a GUI to
> > > > help
> > > > the user.
> > >
> > > Uh, no. A filesystem was a way to organize data that made it easier for
> > > ancient computers to organize data. They existed long before GUIs.
> > > They have well-known shortcomings of their own (e.g., files cannot be in
> > > two different locations in the hierarchy at the same time).
> >
> > Isn't that what a hard link accomplishes?
>
> Only on a local filesystem, which isn't necessarily what the hierarchy
> represents. It also creates what amounts to a new file/node in the
> filesystem, rather than representing a unique file in multiple
> locations. Like symbolic links and aliases, it's a handy hack that
> works around the filesystem's limitations, but it generally doesn't
> reflect how the user *actually* wants to manage the data.

And how doest the user *actually* want to manage the data?

[bi...@mix.com]

Wes Groleau <Grolea...@freeshell.org> writes:

> So far, I have no problem with the Mac filesystem.
>
> But I am starting to suspect Apple is willing to drive away a million of
> us geeks in order to lure five million non-geeks away from Microsoft.

So far, I have no problem with simply avoiding newer Apple products.

To be clear, the older Apple products I do have are entirely adequate.

Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number

[bi...@mix.com]

Kevin McMurtrie <mcmu...@pixelmemory.us> writes, quoting me:

> > Since said filesystem is still there, I'd guess a symbolic link
> > would solve the OP's problem.
>

> Has anyone gotten that to work? I suspect that a symlink won't fool the
> security barrier. (I will not buy any sandboxed apps so I can't try it.)

I don't know (which is why I said I'd guess), but since Wes Groleau
spelled out how to do it, I'd be interested in hearing what happened.

[bi...@mix.com]

Paul Sture <nos...@sture.ch> writes:

> I have just downloaded EasyFind and will add it to my arsenal.
> Thanks to you and dorayme for mentioning it.

It's good. Another good one, which can search with root permissions
(via Option-clicking it's Find button) is Find Any File -

http://apps.tempel.org/FindAnyFile/

[Wes Groleau]

On 07-29-2013 17:31, bi...@MIX.COM wrote:
> Kevin McMurtrie <mcmu...@pixelmemory.us> writes, quoting me:
>
>>> Since said filesystem is still there, I'd guess a symbolic link
>>> would solve the OP's problem.
>>
>> Has anyone gotten that to work? I suspect that a symlink won't fool the
>> security barrier. (I will not buy any sandboxed apps so I can't try it.)
>
> I don't know (which is why I said I'd guess), but since Wes Groleau
> spelled out how to do it, I'd be interested in hearing what happened.

I forgot the Mac apps are also sandboxed. It probably won't work.
A hard link MIGHT work, but is it still disallowed for a directory
to be a hardlink?

--
Wes Groleau

Ostracism: A practice of sticking your head in the sand.

[Doc O'Leary]

In article <tom_stiller-8097...@news.individual.net>,

Tom Stiller <tom_s...@yahoo.com> wrote:

> And how doest the user *actually* want to manage the data?

Different users have different needs for different data. In particular,
the scenario I've seen most that is made difficult without an
abstraction above the filesystem is the common case of putting together
a complex presentation or web site or app. The assets may get organized
by client name as well as by internal department and/or by assigned
worker that each do different parts of the project. A company changes a
logo and you have to scour across all your systems to make sure you've
updated everything.

In general, you find that the best solution that is put in place is some
sort of version control system, and that repository becomes the de facto
"one" location for files (which actually doesn't fix the problem of
potential duplicates). It's far messier to do it that way for the end
user, but without OS support for a better way of managing data, it's
something they'll suffer through.

And on the flip side, I often want my data redundantly located on
multiple filesystems. Conceptually, backup systems and version control
systems serve much the same purpose, but they seem to be seen as
different things by most software. It seems like it would make a *lot*
more sense, especially in these days of multi-TB HDs, for the OS to
present a different view of data than the same ol' dumb hierarchical
filesystem.

[Bread]

On 2013-07-30 19:06:07 +0000, Doc O'Leary said:

> In article <tom_stiller-8097...@news.individual.net>,
> Tom Stiller <tom_s...@yahoo.com> wrote:
>
>> And how doest the user *actually* want to manage the data?
>
> Different users have different needs for different data. In particular,
> the scenario I've seen most that is made difficult without an
> abstraction above the filesystem is the common case of putting together
> a complex presentation or web site or app. The assets may get organized
> by client name

or project or whatever.

More than that, though, is the issue of content which is used in one
way or another by more than one app. iOS uses a "send to app" method
which is at best a bandaid.

Until something better than a filesysem which can be accessed by
multiple apps comes about (note that this does *not* require it to be
the traditional "tree-like" structure that we usually use), there's no
substitute. iOS is terribly hobbled by this and if the Mac goes that
way (and thankfully, generally, there's no indication that it is, other
than the unfortunately poorly built app I posted about to start this
thread), it'd lose a huge swath of the productive community.

App-based file silos aren't as big a deal when you're just a content
consumer, though it can still be annoying (try attaching a file to an
e-mail, for example).

But it makes it awfully difficult to do a lot of things we all take for
granted on the desktop.

Anyway, as I said, in the case of MacFamilyTree, I just wanted to make
sure I wasn't missing something when they blamed Apple's guideliness
for their unfortunate choice. The evidence seems quite strong that
they simply misunderstood (or more likely, misreprestented) what the
guidelines require.

One other poster suggested that they did so intentionally so that they
wouldn't have to write the code that handles the data store separately
for iOS and for the desktop. I don't know how much overlap they get
out of a common code base between the two, but that's at least as
plausable an explanation as anything else I've seen.

The only other thing I can think of is that it was specifically so that
the only way that syncing can be done is via iCloud, which is
obviously, in my opinion, a very poor idea. However, it may make
sense in that iCloud's syncing features go well beyond simply syncing a
copy of a file as Dropbox/Wuala/SpiderOak etc. do. (i.e., Core Data
and the use of transactions). In fact, Dropbox seems to be headed
towards something like that, too:
<https://www.dropbox.com/developers/datastore/docs/ios>

Who knows. I would really like to hear MFT's explanation, though. If
I hear back from them, I'll let folks know.

[Kevin McMurtrie]

In article <ktb7r2$q86$1...@reader1.panix.com>,

You need to read Apple's developer documentation that I posted earlier.
You can also Google "Apple sandbox". Apple is more screwed up than you
can possibly imagine. Expect most developers to abandon Apple when
"Trash Can Mac" doesn't sell well.

The authors of MacFamilyTree are telling the truth when they say that
direct filesystem access outside of the app's sandbox is not possible.
A user would need to perform an import or export action for access to be
temporarily granted.

[Bread]

On 2013-08-01 04:55:28 +0000, Lewis said:

> In message <51f9d535$0$52793$742e...@news.sonic.net>

> Kevin McMurtrie <mcmu...@pixelmemory.us> wrote:
>
>> The authors of MacFamilyTree are telling the truth when they say that
>> direct filesystem access outside of the app's sandbox is not possible.
>

> That is completely untrue.

Seemed pretty obvious, inasmuch as, well, pretty much every other app I
get from the Mac App Store can access and save and modify files in any
normal user-accessible place.

I'm sure that there are specific circumstances where an app is required
to be sandboxed in, but it isn't clear to me how, in any way, MFT
should fall into those circumstances.

[Bo Davis]

Use this link to find out how to access files in iCloud with your Mac.
Very simple.
http://reviews.cnet.com/8301-13727_7-57496273-263/access-icloud-files-using-the-finder-in-os-x/