World: r3wp

** 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?

load each of the files on each own, using 'load and a loop? 'load 
should fail on unloadable things.

the 14,000 lines or so are assembled together into one file for encapping. 
 Hard to split up again .. but I found the fault eventually.

But it would be nice if encap gave a line error instead of just complaining 
it can't load

load would give you the line number

(well, if a ] is missing then will give the end of file of course.)

You could load each file until the one with missing bracket is found, 
then copy chunks of text and try to load them in the console repeatedly, 
eg:
	load read clipboard://

Or just keep trying to load the file while commenting smaller and 
smaller chunks of code. That's what I usually do.

Doesn't the Official Guide have a "debug loader" that islotes the 
missing bracket to the nearest object/function?

Yes. It has some limitations, but there is one there.

you can also use just parse for brackets, almost a parse one liner 
:) but the accuracy depends on what bracket is missing. if it's the 
closing bracket, you can only guess by indentation.

A one liner?? Let's see :)

if you know that the problem is [, just count up on [ and down on 
] and stop when count < 0. or you can just print only the lines with 
[ or ] in them so you get a "compressed" view of the source and look 
for the missing bracket visually.

The problem actually turned out to be Leo ... and the way I was using 
it.  I commented out a block of code using ; when I should have used 
@, and @c .. so it only commented out the first line of the included 
block :(