Thanks Stephen - this isn't one of my Dreamhost sites, it's still on
on-rev.
I am 99% sure the downloads directory was readable at one time - but
I've decided to keep the extra security of explicitly deciding which
URLs to to give out, and to whom - rather than a more permissive (even
if filt
This has been standard practice for shared hosting at Dreamhost for years.
I made an index.irev file that looked at the contents of the directory and
displayed a list, subject to filtering. Parameters set with simple txt
file. Very easy.
sqb
--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.or
Most likely directory browsing is turned off. You could change the
setting, or you could put in an irev that gets "the files" and builds a
link list dynamically, minus itself of course.
On Sat, Dec 3, 2016 at 3:54 PM, Alex Tweedly wrote:
> You're right - and I confess I don't know why the downl
You're right - and I confess I don't know why the downloads folder is
inaccessible. Permission is set to 755, and there's no .htaccess file or
anything else I know of to prevent it.
Anyway - if you wanted the taskrunner files, they are :
- taskrunner.rev
- taskClientLib.rev
- test-task-runne
Very strange - the correct URL is
http://tweedly.org/downloads/checkpermissionsetting.livecode
i.e. without the last 's'
Did you know that, in Chrome, if you modify the URL, and it turns out to
be a downloadable file - then Chrome downloads it, and then changes the
visible URL in the address
Hi Alex,
Downloads folder in your server is not accessible.
It's not possible to download this stack either:
http://tweedly.org/showpage.lc?page=taskRunner
Al
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscri
On Sat, Dec 3, 2016 at 9:47 AM, Alex Tweedly wrote:
> It's at http://tweedly.org/downloads/checkpermissionsettings.livecode
>
Not Found
The requested URL /downloads/checkpermissionsettings.livecode was not found
on this server.
Additionally, a 404 Not Found error was encountered while trying
OK, I got slightly lost in this thread - we've gone off to solve a
work-around to your problem, and I'd like to go back to the problem itself.
If I understood it properly, what you;re seeing is that setting the
permission of a directory to disallow write *should* prevent you from
saving a sta
I've added the following after setting the name, and also moved the save
into this block:
*if* (char 1 to 6 of bkNm) <> (char -17 to -12 of the long name of this
stack) *then*
*--date has changed*
bmpVrsn stkNm
*else*
*save* this stack
*end* *if*
bmpVrsn is my routine to bump the filename.
On Fri, Dec 2, 2016 at 12:01 PM, Mike Bonner wrote:
> Not sure I understand this but... You open a stack, and then try to change
> the permissions of the directory that it resides in so that you then can't
> save it? Since the file is already open and "in use" i'm not sure its
> actually possibl
Not sure I understand this but... You open a stack, and then try to change
the permissions of the directory that it resides in so that you then can't
save it? Since the file is already open and "in use" i'm not sure its
actually possible to change the permissions under those circumstances.
If you
On Fri, Dec 2, 2016 at 11:20 AM, J. Landman Gay
wrote:
> On 12/2/16 12:55 PM, Dr. Hawkins wrote:
>
>> *--livecode's own stacks*
>>
>> *case* char 1 to 3 of stkNm="Rev"
>>
>> *case* stkNm="Message Box"
>>
>
> This is no longer the case. Some of LC's stacks no longer start with
> "rev". It probably
On Fri, Dec 2, 2016 at 11:05 AM, Bob Sneidar
wrote:
> So what *actually* happens when you save a file is, the old file is
> renamed by prepending a tilde (~) to the filename, then an attempt to save
> the file as the original is attempted. If all goes well, the backup copy is
> deleted. So in a s
On 12/2/16 12:55 PM, Dr. Hawkins wrote:
*--livecode's own stacks*
*case* char 1 to 3 of stkNm="Rev"
*case* stkNm="Message Box"
This is no longer the case. Some of LC's stacks no longer start with
"rev". It probably doesn't matter if you back those up anyway, but just
so you know.
--
Jacqu
So what *actually* happens when you save a file is, the old file is renamed by
prepending a tilde (~) to the filename, then an attempt to save the file as the
original is attempted. If all goes well, the backup copy is deleted. So in a
sense you are not actually saving, you are saving as.
Some
On Fri, Dec 2, 2016 at 9:59 AM, Rick Harrison
wrote:
> Ok, so it sounds like you are using an LC stack file.
> You are opening that LC stack from within LC
> so LC/macOS, (assuming your are on a Macintosh Computer),
> is going to update the “Date Modified” date because LC/you
> have touched the f
Ok, so it sounds like you are using an LC stack file.
You are opening that LC stack from within LC
so LC/macOS, (assuming your are on a Macintosh Computer),
is going to update the “Date Modified” date because LC/you
have touched the file. That’s built into the OS and is
deliberate.
What I do
On Thu, Dec 1, 2016 at 4:08 PM, Rick Harrison
wrote:
> If you just want to prevent overwriting of older files,
> why don’t you just use a new name for the file.
>
This is about protecting me from accidental saves.
There are a dozen or so separate files. I want a new "main" stack for
every edit
Hi Dr. Hawkins,
If you just want to prevent overwriting of older files,
why don’t you just use a new name for the file.
You can always track which file is the newest in a few
different ways.
For Example: File1, File2, or append a date and time to the file name.
At the end of some larger time
On Thu, Dec 1, 2016 at 11:32 AM, Dr. Hawkins wrote:
> I'm trying to put in a failsafe that prevents overwriting older files. Do
> I need to change the owner of the files for this???
>
That doesn't do it either:
get shell ("chmod -w " & oldFlDir && "; chown dhArchive " & oldFlDir)
gets
chown
livecode seems to be gratuitously unlocking directories.
I launch live code, and then "chmod -w" the directory of the stack. On
quit, it restores write permission!
If I use shell (chmod -w someDir), it apparently unlocks it before
returning from shell!
I'm trying to put in a failsafe that preve
21 matches
Mail list logo