World: r3wp

gabriele - how does it relate to my report?

I strictly refuse following result:

>> exists? %rebol.exe
== true
>> exists? %c/
== false

both queried items are result of regular 'read function call on filesystem 
...

>> change-dir %/
== %/
>> exists? %c/
== true

still does not explain my results

what is first slash representing? It is a root-dir? Then it might 
make sense. Or is it just a syntax?

Yes, filesystem root.

then your example stands for something like following?

>> exists? join %/ %c/
== true

Yep.

so that %c/, even if being a drive assigned letter, is being treated 
as a directory here ....

hmm, ok, I will remember it, but it might confuse some ppl ....

Yes.  I think this is Rebol's way of handling Windows unique drive 
system.

Sunanda - here is one fine doc about all possible modes - http://rebol.com/docs/changes.html#section-6.2

somehow can't set-modes for directory :-)

is there a bug or what? Can copy-modes be set for directory too?

>> modes: get-modes %sqlite/ get-modes %sqlite/ 'copy-modes

== [creation-date: 2-Jul-2007/10:20:05+2:00 access-date: 2-Jul-2007/10:20:07+2:00 
modification-date: 2-Jul-2007/
10:20:07+2:00 owner...

>> set-modes %sqlite/ modes
** Access Error: Cannot open /c/!rebol/view/sqlite/
** Near: set-modes %sqlite/ modes


I simply wanted also my copied directories, not only files, to carry 
on original attributes ....

Pekr, 
>>exists %/c/
= true

... even when not in the root directory.

>> exists? %/c/
== true
>> what-dir
== %/C/Program Files/rebol/view/
>>

Petr, I'm not sure what you want. Obviously %c/ is a dir, and obviously 
it is at the root, so you have to access it as %/c/. This is called 
platform independent file paths. It's the same for all platforms.

Brock, I was confused about reading %/ and getting %c/ instead of 
%/c/, that is all. I did not regarded %/ a root, I thought it is 
just a helper, as %. is .... that dot surely is not real part of 
filesystem, is it?

I resolved it for myself by defining root: %/ and joining it with 
the result of the read, works .... new problem for me is how to set 
attributes of copied directory. Not sure why do I receive error. 
It seems like that dir would be locked or so, but not sure why set-modes 
fail. Is set-modes supposed to work with directories?

no

I reported this a couple of years ago .. it does not work

ok, thanks a lot ... it is a pity, I don't need it in fact, but found 
that possibility in docs, tried it, and it nicely works for files 
....

and is there a way to create directory not using make-dir, directly 
setting such attributes during creation process, not later?

Petr, that dot (%./) *is* part of the filesystem in most filesystems.

Can I get following solved somehow, without defining globally visible 
word?

report: does [print item]
foreach item [1 2 3][report item]

Given 'does is simply a shortcut for 'func, why not:
    report: func [item] [print item]

because I want to have clean interface to my copy-dir source target 
.....

the trouble is, that later on, I dynamically detect new drive. I 
can't know, what letter usb drive maps to. So I do:

forever [

  for each disk difference stored-disks read %/ [copy-dir source target]
]

foreach item [1 2 3] [do bind second :report 'item] may work

And I somehow wanted to have 'disk available in my copy-dir :-) Well, 
I can easily solve it via drive: disk and use drive global word in 
my copy-dir func. It is just that I was thinking if I can somehow 
magically bind to it :-)

I need it vice versa - bind item in report to foreach item ....

but no problem, I can get it working other way, I was just curious 
...

That will bind report and item to the local foreach item.

Well actually it binds print and item  to the local item.

ah .... I tried to look at it from the perspective of report function, 
and was stuck ....

Yeah bind is a little ummm, magically delicious.

I have weak USB port, and my flash disconnects from time to time. 
I am testing my copy-dir small script, and during disconnection it 
failed. I had following code there:

attempt [
  data: read/binary source
  write/binary target data
]


Shouldn't attempt catch the error, even if I am in the middle of 
copying of file?

imho.  yes it should.

I've been a little curious about attempt...
if not error? set/any 'value try :value [get/any 'value]

Are there any conditions where the [get/any 'value] could fail and 
as it is outside the try cause an interpreter error trap?  I don't 
know.

Pekr: "because I want to have clean interface to my copy-dir source 
target" - I may be dense, but what is "unclean" there?

got to go, but I don't want to send another parameter (drive letter) 
to the function ...

So what I did was, that I defined one word inside foreach loop, which 
will be accessible from other place. It if sufficient, but what is 
"unclean" about it is, that I somehow start to think, that more strict 
way of defining variables is better than globals "floating around" 
:-)

petr, why is not the disk in the source argument?

inside foreach and accessible somewhere else == global. the proper 
way to do it is a function argument. you can bind, but that does 
not seem clean to me (argument is clean).

and to me it looks like you have the argument already.

'attempt seems not to be able to catch file reading error. What am 
I doing wrong? Should I use if not error? try [] instead?

What do you mean Pekr, it seems OK to me:
>> attempt [read %no-file]
== none

Rebolek - well, try to attempt [data: read/binary %some-larger-file] 
.... unplug your usb flash when file is being read ....