Thanks, Ric and Bill.

Just so's I know it's working for me and not somebody else. I'd hate to
distribute an app – even a beta – especially a beta – which goes around
slurping the user's intellectual property.

Xcode appears to have total control over the snap directory. Unlike
Apple:Finder (which as a rule hides dirs/files beginning with dot) it can
open ~user/snap/.snp – and edit or delete its contents. Though I haven't
tried… like Bill, I shy away from trashing things I don't understand.
Unless I have a spare week to explore the consequences.

Right now, it contains an old copy of just one J script – nested in
gibberish directories. I've no idea what I did to snapshot that one
particular script, and I feel it's something I need to know. It's a vital
script and would cause big trouble if it ever got executed… or regressed. I
may just delete its contents and make it say a rude message if/when it's
ever loaded. A great use for the Mac's superb text-to-speech facility: you
can even make it say it in Russian. (Suggestions, please…)

JQt Autosave, eh? Bill and Ric reinforce my suspicions. If it's owned by
jqt then I'll take a chance it won't alter. Because I don't have jqt in my
mini-installation, which is for JHS only.

BTW: I don't see a lot here about JHS as a faceless daemon talking through
a pretty Apple face, whether macOS or iOS. But I'm convinced it has a
future, and now I have hard evidence. If anyone on this list is working
along similar lines and wants to see where I'm up to, pm me and I'll
cheerfully zip-up an Xcode project or two and email you a box link.

Ian


On Sat, Jul 8, 2017 at 4:31 AM, bill lam <[email protected]> wrote:

> I think snap have been there for over may year. It
> autosave recent versions during edit session.  In J8 you can
> use config to set maximum number of snapshot or disable it.
> But I suggest you do not disable it even if you think you don't
> need its service.  Perhaps it can help you just in case.
> You can delete its content when you think they are no
> longer needed.
>
> You may add a run script in xcode build phases to automatically trash
> files inside the snap folder. (untested)
>
> snap folder may or may not be re-created, this depends on your
> profile.ijs or profilex.ijs
>
> Сб, 08 июл 2017, Ian Clark написал(а):
> > Inside an Apple Xcode project, I am managing a cut-down J805 installation
> > which gets embedded in the resulting app. The app (TABULA) is nearing the
> > beta-test stage and I must attend to questions of security. Such as: its
> > capacity for harboring concealed trojans.
> >
> >
> > Xcode has discovered J code I didn't know existed in a folder:
> > J64-805-user/snap/
> >
> > This folder seems to be created at installation time of J64-805 itself,
> and
> > my mini J installation has inherited it. It is moderately large (88KB),
> but
> > not as large as /Applications/j64-805/addons (36.4 MB).
> >
> >
> > When I open it in osx Finder, it pretends to be empty. But Xcode/Find
> makes
> > its contents perfectly visible. More to the point, Xcode allows me to
> edit
> > this J code -- and the edit persists across finds.
> >
> >
> > I recognise some of the contents as J source code I myself have written,
> > maybe out-of-date code.
> >
> >
> > ++ Can I safely delete J64-805-user/snap/ from my Xcode project folder?
> > What, if anything, will fall over as a result? Will J64-805-user/snap/
> get
> > re-created inside the distributed app? Maybe even restored?
> >
> >
> > ++ Can the J code inside J64-805-user/snap/ conceivably be executed? I
> > would like to be reassured it never can.
> >
> >
> > I have searched http://code.jsoftware.com/wiki/ for the word "snap" but
> the
> > results cast no light on the matter for me.
> >
> >
> > I can take a shrewd guess at what /snap/ is intended to do. But to guess
> is
> > not to know. Can anyone help, please?
> >
> >
> > Ian Clark
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to