World: r3wp

will try. but i thought about viewtop.  alsthough that one can be 
patched.

this is the source: http://www.fm.tul.cz/~ladislav/rebol/include.rmd

Thanks.

When I #include http:///www.an.example.com/directory/script.rit 
gives an error that it can't find script.r even if I've appended 
the url directory to the include path ... maybe I'm assuming something 
somewhere

The mouse click thing works for me by the way :)

this works for me, did you try something like that?

>> save %test.r [rebol [] #include http://www.fm.vslib.cz/~la
dislav/rebol/lfunc.r]
>> print read %test.r
rebol [] #include http://www.fm.vslib.cz/~ladislav/rebol/lfun
c.r
>> include %test.r
connecting to: www.fm.vslib.cz
connecting to: www.fm.vslib.cz
>>

(sorry for line breaks)

Andrew: I haven't published the changed prebol. (I was actually hoping 
for Carl to make it the default in the future.) The problem with 
it is that encmdview would still run with the standard prebol since 
it is built into the exe, so you would still have some problems. 
In the end, it's probably better to use Ladislav's INCLUDE function 
as it gives you more flexibility, and I guess it'll become the default 
too in the future.

The following is typed not pasted ...

>> do http://www.fm.vslib.cz/ladislav/rebol/include.r

>> save %test.r [REBOL [] #include http://www.absentis.com/files/rebol/library/libadl/libadl.r]

>> include %test.r

** Access Error: Cannot open /c/Documents and Settings/kccadl.KAS/var/website/files/rebol/scripts/libadl.r

** Where: include-script

** Near: found: load/all target

if header

>>

If I made a typing mistake above it wasn't in the original, as you 
can see I get an error including the file via http, that same file 
works perfectly when i do it ...

Someone reported this error .. "The file "...exe" contains more than 
one data stream, but the destination volume does not support this 
feature.  Some data will not be preserved as a result" .. what does 
this mean for encapped apps?

Oh, yeah, it also says "Information that will not be preserved includes 
:Zone.identifier:$DATA"

hmm, i think you can safely ignore it. i don't think rebol has anything 
to do with it. NTFS allows for multiple content to be associated 
with a file name, but almost noone is using this feature i think 
(like for links); so something on that system added a data stream 
to the exe file.

i don't know much of how this works - a Windows expert may be of 
more help.

new SDK works differently? It does not contain prebol.exe, but it 
contains prerebol.r ...

is it now all done by en-face for .e.g, which first automatically 
calls prerebol?

hehe, now I know, why rebol/view does not mind #include %../sources/view.r 
line :-)) it just interprets it as issue! and file! :-)

Graham, multiple data streams are how Mac files are stored on Windows 
servers. Also, some antivirus programs use the extra streams for 
storing checksum data, some viruses for storing their payload, the 
system for storing file metadata, and various applications for obscure 
reasons. Any file copy program that ignores multiple data streams 
does so at the user's peril. Since there are few such programs written 
in REBOL (Carl's recent blog post notwithstanding), the lack of data 
stream support in REBOL isn't much of a problem for now.

Interesting ...

So, just plain read and write does not touch the alternate data stream

that must be a trap for anyone writing a file replication tool.

Well, REBOL supports file forks on Mac in a way that you can use 
the same code between Mac and other platforms - the other platforms 
just pretend to have a data fork. However, alternate data streams 
on NTFS are not supported by REBOL so you can get tripped up there.

This thread from the ML would indicate otherwise: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlZCSJ

Well, it's nice that they are semi-supported through a filename hack 
that is actually in the underlying APIs that REBOL calls internally, 
but it is not supported through the actual mechanism REBOL uses for 
supporting that kind of thing on other platforms, and so is not portable.


Try get-modes %file 'forks or the /custom refinement to open, read 
or write with the [fork "forkname"] parameter. On platforms other 
than Mac there is generally only one fork ("data") but if the code 
you write is fork-aware it will be portable. This is the method that 
REBOL should be using to support streams on NTFS or any equivalent 
feature on other OSes' file systems.

Much of the description of NTFS streams and their limitations, as 
expressed by Robert Muench in your link, refer to limitations in 
non-stream-aware code. Windows has APIs that handle streams quite 
nicely AFAIK, including retrieving the names of the streams and deleting 
them if you want to do so without deleting the file or directory 
they are attached to.

Funny, reading on it turns out that I actually participated in that 
thread. My, how time flies... :)

How works this filename-hack? And would it make sense to check for 
that for security-reasons for uploads? currently icheck for "is in 
subfolder", can these things add some kind of exe-attribute?

<filename>:<stream>:$<attribute> without the < and > of course. Since 
the default stream is the empty string and all attributes start with 
$ you can skip one of the colons with default attributes. The default 
attribute is $DATA, and what you would normally think of as the contents 
of %file would be in %file::$DATA really.


Executable files aren't marked as such with attributes like they 
are in Unix, but you can hide stuff in alternate streams. It wouldn't 
matter what the file was named if you could pass it to CreateProcess 
or some such, so you can hide executable code in alternate streams 
but without library support you can't call it. You should validate 
the filenames of files you are serving for security anyways, so this 
is just one more thing to look for.

I am not sure what all of the details are about the semantics of 
this. It would be nice if REBOL was really stream-aware so we wouldn't 
have to worry about things like this.

But does Rebol have a way to determine what the FS is on a partition 
without calling Win API ?

Not really. As it is, there are certain characters that shouldn't 
be in Windows filenames and the colon is one of them. Screening for 
them is a good idea.

Good explanation. That verifying was what i was looking about. Fortunally 
that ":" would not pass my letter-only rule, phew :) But maybe the 
sandbox should take this into account too?

REBOL should be stream-aware, period. Preferably using the same fork 
syntax that it uses on Mac and everywhere else.

right, that would fix it.

There is no reason to let that weird NT file-stream-name syntax infect 
REBOL file! syntax if we can avoid it, especially since we already 
have a mechanism for dealing with this kind of thing (and I use the 
term loosely - the underlying semantics are different on every platform).

By the way, the quickest way to determine the characters you need 
to screen for on Windows is to try to change a filename in Windows 
Explorer and type one of those characters. A baloon help message 
will pop up listing the characters that you shouldn't use.

are ":" used somewhere? macs, amiga-assigns?

Yes, but only in local files, not REBOL file syntax.

ok.

what strategies do people use when you have a few mbs of source, 
and the encap dies due to unmatched brackets ... how to locate the 
offense easily?

lots of alchohol or other stimulant

just a joke. is it impossible to backtrack the change in the sources 
or did the error not show up until you tried to encap?