AltME groups: search

I was also getting it (linux), but now it the file appears to be 
gone and it's stopped

Let us know if this continues Max. File sharing has been disabled 
on this world, but there seems to be a glitch. I haven't seen it, 
and it's cleared up for others, so you may be our special test case 
to help track it down.

Is there a log file mode to activate?

It'd be interesting to know the size of Graham's private messages 
file  -- 19.set in his case.  {Andreas, yours would be 107.set]

The files should be in altme/worlds/rebol3/chat

But beware that Windows may be virtualising the files, so the latest 
copy may be well hidden elsewhere,

My private messages file is 384K.

doing an OS (file content) search in the altme directory usually 
is easier and faster too.

My guess is that it's the server that takes time to append the message 
in the chat file.

Dunno if it does a simple append to the file but if it needs to load 
it in memory, append the block, then write it down to disk, it could 
explain why bigger chat files take longer to update !!

Looking at my Altme file activity (Filemon) when I post a message 
:

- Nothing happens until the server has done its job and send back 
the new message for the corresponding group/user.

- Then I see that the corresponding chat file is wrote entirely by 
block of 4096B !

- Then the state file (chatMYALTMEID) is updated (wrote by chunk 
of 4096B).

[I'm just guessing here] There are at least three different data 
sets to update when I send a private message to (say) Graham:
-1- my chat local *.set file

-2- whatever data sets are held on the server to record the message 
(I have no idea what these are)
-3- Graham's local *.set file


The first two could contribute to perceived slowness in sending; 
the third to any apparent slowness in updating/downloading messages.


Append/lines to a 4.5 meg file does not take long on my machine (not 
does read/lines) so I'm primed to suspect the problem is on the server.


What would be interesting to know is if the grayness I see when sending 
a message ends when:
-a- the server acknowledges receipt; or
-b- when the server has finished committing all its updates.


If it is -b-, then moving the server response to be -a- could create 
a significant perceived increase in responsiveness.

James : It would be interesting for us if you can look the file activity 
of a world server when a new post is send.

I use Filemon from Sysinternals (no included in Process monitor) 
for that.
Can you test this for us and tell us what happens ?

Didier, Process Monitor includes both file and registry monitoring 
- it effectively obsoletes regmon and filemon. You might be thinking 
of Process Explorer.

4:57:00.5195412 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: 
Sequential Access, Synchronous IO Non-Alert, Non-Directory File, 
Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Opened

4:57:00.5198317 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5200764 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\chat\18.chg	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:20:09 PM, LastAccessTime: 9/25/2010 4:55:35 PM, LastWriteTime: 
9/25/2010 4:55:35 PM, ChangeTime: 9/25/2010 4:55:35 PM, FileAttributes: 
A, AllocationSize: 296, EndOfFile: 292, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x1000000002fd2, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5209299 PM	altme.exe	1492	QueryStandardInformationFile	C:\Program 
Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	AllocationSize: 
296, EndOfFile: 292, NumberOfLinks: 1, DeletePending: False, Directory: 
False

4:57:00.5211763 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	Offset: 
292, Length: 4

4:57:00.5215235 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\chat\18.chg	SUCCESS	

4:57:00.5243792 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:00.5246281 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\chat	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:00.5248293 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\chat	SUCCESS	

4:57:00.5248513 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara\chat	SUCCESS	

4:57:00.5256763 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\chat\18.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5259221 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\chat\18.set	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:20:09 PM, LastAccessTime: 9/25/2010 4:57:00 PM, LastWriteTime: 
9/25/2010 4:57:00 PM, ChangeTime: 9/25/2010 4:57:00 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x1000000002fd3, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5263666 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
0, Length: 4,096

4:57:00.5267764 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 4,096, Length: 4,096

4:57:00.5270125 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
4,096, Length: 4,096

4:57:00.5277232 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
8,192, Length: 4,096

4:57:00.5280137 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
12,288, Length: 4,096

4:57:00.5282825 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 16,384, Length: 4,096

4:57:00.5285077 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
16,384, Length: 4,096

4:57:00.5288736 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	Offset: 
20,480, Length: 3,470

4:57:00.5291306 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	

4:57:00.5292988 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara\chat\18.set	SUCCESS	

4:57:00.5299280 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\registry.chg	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: 
Sequential Access, Synchronous IO Non-Alert, Non-Directory File, 
Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Opened

4:57:00.5301501 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\registry.chg	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5303400 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\registry.chg	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:19:53 PM, LastAccessTime: 9/25/2010 4:55:35 PM, LastWriteTime: 
9/25/2010 4:55:35 PM, ChangeTime: 9/25/2010 4:55:35 PM, FileAttributes: 
A, AllocationSize: 77,824, EndOfFile: 74,727, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x1000000002e83, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5305657 PM	altme.exe	1492	QueryStandardInformationFile	C:\Program 
Files\altme\servers\nakakihara\registry.chg	SUCCESS	AllocationSize: 
77,824, EndOfFile: 74,727, NumberOfLinks: 1, DeletePending: False, 
Directory: False

4:57:00.5307507 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\registry.chg	SUCCESS	Offset: 
74,727, Length: 4

4:57:00.5317625 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\registry.chg	SUCCESS	

4:57:00.5355275 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:00.5357293 PM	altme.exe	1492	CreateFile	C:\Program Files\altme\servers\nakakihara	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:00.5358812 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara	SUCCESS	

4:57:00.5359027 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara	SUCCESS	

4:57:00.5366269 PM	altme.exe	1492	QueryInformationVolume	C:\Program 
Files\altme\servers\nakakihara\registry.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:00.5368179 PM	altme.exe	1492	QueryAllInformationFile	C:\Program 
Files\altme\servers\nakakihara\registry.set	BUFFER OVERFLOW	CreationTime: 
2/12/2010 1:19:53 PM, LastAccessTime: 9/25/2010 4:57:00 PM, LastWriteTime: 
9/25/2010 4:57:00 PM, ChangeTime: 9/25/2010 4:57:00 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x300000000002e84, EaSize: 
0, Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:00.5371021 PM	altme.exe	1492	WriteFile	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	Offset: 
0, Length: 3,544

4:57:00.5374496 PM	altme.exe	1492	CloseFile	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	

4:57:00.5375367 PM	altme.exe	1492	IRP_MJ_CLOSE	C:\Program Files\altme\servers\nakakihara\registry.set	SUCCESS	

4:57:04.5427517 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5429673 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5431218 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5431436 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5438713 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\registry.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:04.5440655 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\registry.set	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:17:46 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x50000000026e1, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5443479 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	Offset: 
0, Length: 3,298

4:57:04.5452260 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	

4:57:04.5453489 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\registry.set	SUCCESS	

4:57:04.5535307 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5537371 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5538911 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5539140 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara	SUCCESS	

4:57:04.5545705 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\state	SUCCESS	VolumeCreationTime: 2/12/2010 
10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: True, 
VolumeLabel: 

4:57:04.5547627 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\state	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:17:46 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x100000000da8a, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5550102 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	Offset: 
0, Length: 184

4:57:04.5552809 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	

4:57:04.5553641 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\state	SUCCESS	

4:57:04.5712081 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5714824 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5716849 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5717076 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5725515 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:04.5727921 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\chat\18.set	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:18:22 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x100000000dac0, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5732424 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
0, Length: 4,096

4:57:04.5736452 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 4,096, Length: 4,096

4:57:04.5738807 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
4,096, Length: 4,096

4:57:04.5742406 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
8,192, Length: 4,096

4:57:04.5745250 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
12,288, Length: 4,096

4:57:04.5747951 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	FAST 
IO DISALLOWED	Offset: 16,384, Length: 4,096

4:57:04.5750261 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
16,384, Length: 4,096

4:57:04.5753840 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	Offset: 
20,480, Length: 3,467

4:57:04.5756441 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	

4:57:04.5761567 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat\18.set	SUCCESS	

4:57:04.5788099 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	Desired 
Access: Generic Write, Read Attributes, Disposition: OverwriteIf, 
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory 
File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: 
Overwritten

4:57:04.5790912 PM	altme.exe	12200	CreateFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	Desired 
Access: Synchronize, Disposition: Open, Options: Directory, Synchronous 
IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, 
AllocationSize: n/a, OpenResult: Opened

4:57:04.5792937 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5793150 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat	SUCCESS	

4:57:04.5801410 PM	altme.exe	12200	QueryInformationVolume	C:\Program 
Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	VolumeCreationTime: 
2/12/2010 10:37:05 AM, VolumeSerialNumber: 000E-5EC7, SupportsObjects: 
True, VolumeLabel: 

4:57:04.5803791 PM	altme.exe	12200	QueryAllInformationFile	C:\Program 
Files\altme\worlds\nakakihara\chat\chat4	BUFFER OVERFLOW	CreationTime: 
2/21/2010 8:18:23 PM, LastAccessTime: 9/25/2010 4:57:04 PM, LastWriteTime: 
9/25/2010 4:57:04 PM, ChangeTime: 9/25/2010 4:57:04 PM, FileAttributes: 
A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: 
False, Directory: False, IndexNumber: 0x100000000dadf, EaSize: 0, 
Access: Generic Write, Read Attributes, Position: 0, Mode: Sequential 
Access, Synchronous IO Non-Alert, AlignmentRequirement: Word

4:57:04.5807059 PM	altme.exe	12200	WriteFile	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	Offset: 
0, Length: 2,206

4:57:04.5810769 PM	altme.exe	12200	CloseFile	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	

4:57:04.5811630 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\Program Files\altme\worlds\nakakihara\chat\chat4	SUCCESS	

4:57:04.6485821 PM	altme.exe	12200	QueryOpen	C:\WINDOWS\system32\msimtf.dll	SUCCESS	CreationTime: 
3/31/2003 5:00:00 AM, LastAccessTime: 9/25/2010 4:56:24 PM, LastWriteTime: 
8/4/2004 12:56:43 AM, ChangeTime: 2/13/2010 12:50:11 AM, AllocationSize: 
159,744, EndOfFile: 159,232, FileAttributes: A

4:57:04.6488903 PM	altme.exe	12200	CreateFile	C:\WINDOWS\system32\msimtf.dll	SUCCESS	Desired 
Access: Execute/Traverse, Synchronize, Disposition: Open, Options: 
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: 
Read, Delete, AllocationSize: n/a, OpenResult: Opened

4:57:04.6493828 PM	altme.exe	12200	CreateFileMapping	C:\WINDOWS\system32\msimtf.dll	SUCCESS	SyncType: 
SyncTypeCreateSection, PageProtection: PAGE_EXECUTE

4:57:04.6494085 PM	altme.exe	12200	QueryStandardInformationFile	C:\WINDOWS\system32\msimtf.dll	SUCCESS	AllocationSize: 
159,744, EndOfFile: 159,232, NumberOfLinks: 1, DeletePending: False, 
Directory: False

4:57:04.6494267 PM	altme.exe	12200	FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION	C:\WINDOWS\system32\msimtf.dll	SUCCESS	

4:57:04.6494462 PM	altme.exe	12200	CreateFileMapping	C:\WINDOWS\system32\msimtf.dll	SUCCESS	SyncType: 
SyncTypeOther

4:57:04.6494602 PM	altme.exe	12200	FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION	C:\WINDOWS\system32\msimtf.dll	SUCCESS	

4:57:04.6496560 PM	altme.exe	12200	CloseFile	C:\WINDOWS\system32\msimtf.dll	SUCCESS	

4:57:04.6496803 PM	altme.exe	12200	IRP_MJ_CLOSE	C:\WINDOWS\system32\msimtf.dll	SUCCESS

Are there are any benchmarks about max. file-size on AltME and number 
of files it can handle?

or just rename your personal pm file, make it empty ... will that 
resync the old one?

I also have a fairly large private messages file.

Try with someone who does not -- say a Hello message to a new member.

I love AltMe, but it has things that annoy me as well. Since we don't 
know exactly why it doesn't scale (yes, we can guess), I don't think 
just making the back end a DB is a guaranteed fix, or perhaps even 
that simple. And I don't think it will happen. I fear the R3 chat/rebdev/??? 
model will scale even worse than AltMe as I think the msg db is a 
single file and still a naive implementation designed for small-scale 
use.


Like Graham, I've thought that something like Git--a system designed 
for distributed, differenced, repositories of information--might 
be used. I haven't seen it done however.

What ar our options?

1) Live with AltMe, and roll worlds when they get too slow.
2) Find an alternative.
3) Implement our own.

Is #1 painful enough to drive us to #2 or #3?

actually the r3 chat system *client* is still pretty simple... but 
the way messages are managed via the server seems to be much more 
flexible.  every msg and file is its own single item.  they are downloaded 
as items, not as groups of items.


so actually, all that needs to be done to make r3 chat scale is to 
improve how it stores its messages on disk and on RAM.   


the fact that the server supports moderation, threads, user levels, 
files, and things like item re-classification is very nice.


really, all it needs is a gui client.... that's If the server is 
able to respond quickly to requests.

Might also explain the file corruption for restored groups here.

if Carl is just doing a TAR while the altme server is running, it's 
not strange that one or two files don't get backed up correctly. 
a quick workarourd is to keep more than just the last backup, as 
the chance of a file missing from two backups is pretty small.


of course, ideally one would be using ZFS and backing up from a snapshot...

(I am backing them up locally, by the way, if Carl needs anything)


Proper backup tools can't do anything against the altme server overwriting 
the files. Either your filesystem supports snapshots, or the altme 
server has to support the backup operation directly at least by suspending 
file activity while the files are being copied (or, the file storage 
has to be designed so that files are immutable, that way at the very 
least you can't lose old data because of overwriting)

It rewrites your local file, right? It seems that Carl's concept 
of  - keep things simple - in fact turned into - constantly try to 
reinvent the wheel, never finish it properly, don't scale well, or 
at all.

Backup scheme: I suppose the only way is really some kind of snapshot, 
or by having AltME server pack a single file once an hour, that a 
backup system then can grab and stow somewhere.

My personal chat file was reset too (size changed from 1MB to 1KB). 
Luckily I also backed it up 10 days ago, after reading the reports 
here.

Carl - yes, you simply logged on, and found your pms gone, rewritten 
with new file, or something like that.

Not sure it is worth it. Some ppl complained their PMs are really 
slow, because the file was too big already :-) What I am more curious 
about is - what was the reason?

AltME uses a write/append which for some reason on Linux means: if 
you cannot append, truncate the entire file to zero.

Make a backup of your old persona's PM file then, before logging 
in.

Checking for that file now, I see it does not exist!

for my self, I'd like to have the backup file directly, but not restored 
on the server... I had stopped PMs cause at 4.5 MB... slow... doesn't 
even begin to describe it.

AltME uses a write/append which for some reason on Linux means: if 
you cannot append, truncate the entire file to zero.


For performance reasons (blame the early optimization guys), the 
default setting for many file systems on Linux is to write metadata 
independently from data, which means that it often gets written first. 
The result is that if writing the data fails (eg. power failure, 
kernel panic, ...), the files end up 0 length.


This can be disabled by setting the filesystem to always write data 
and metadata at the same time (at the price of write performance).

AltME broken for me....


Background: this morning my Windows computer froze and I had to cycle 
the power on it. (AltME was running, but nothing to suggest that 
AltME was the cause of the problem).


After a reboot, AltME would not start -- complained there was a file 
it could not read.


No worries....I deleted the entire REBOL3 folder, and restarted AltME.


After it had downloaded 40+ meg of messages, all should have been 
back to normal. But the resync process got itself stuck, continually 
resyncing the SQLite group.


I have since tried downloading the whole world again; and I have 
uninstalled AltME completely and started again from scratch. Same 
problem.


Now, if I restart AltME, it looks okay at first. But, if I click 
into the SQLite group (or if someone posts a message to that group) 
the endless resync starts up again.


I am not seeing the problem on a different machine where I have not 
reinstalled AltME.

This is like the opposite of the ancient resync bug :)

***


I suspect the SQLite folder is somehow corrupt on the server; but 
the corruption only triggers trouble on a fresh install.....If so, 
we will all see it eventually :(

Can someone copy this to whoever maintains AltME? Thanks!

Peter Wood has sent me his SQLite file (439.set). Thanks Peter!

Copying that over the one in the /chat folder seems to have cured 
the problem.


So it looks like the server has a corrupt version that it sends out 
on a fresh install.

How to allow more than 8MB of file being uploaded on my AltME server?

I tried to create a zip archive, but it is about the same size, so 
no help. IIRC there was some AltME version, which allowed to use 
bigger sizes? I think it would be good to have it as a command-line 
option for the server startup. It is my private world, and I would 
allow 20MB easily. It is not first time I got file bigger than 10MB 
I needed to post ....

Petr, it's a big security hole, because the AltME server uses a multitude 
of the file size in memory during the upload, which can easily crash 
the server and at least overloads the swap space

I am using altme from time to time from my USB stick (a bit slow, 
due probably to slow flash disk plus the way how altme relies on 
heavy file access, but still usable), and the only thing I need is 
to just copy it ...

The SQLite group is broken ... I suspect a corrupt file on the server.

Symptoms: if you've recently re-installed AltME, then the program 
runs continuously, endlessly resyncing that group.


This happened before, and the workaround was to copy over a good 
copy of the 439.set file (thanks to Peter Wood for the good copy). 
But that no longer seems to work.


I am going to delete the group and set up a new one with the same 
name. The archive  of past postings will remain available here:
    http://www.rebol.org/aga-display-posts.r?post=r3wp439x1

File sharing still suffers greatly from the daylight savings bug, 
though

It seems to try to allocate a 3 GB file or area there. It's not surprising 
that fails, but it's surprising it would try that

In another AltME world I'm participating in, AltME file sharing is 
used to share 103 files, all of which I have downloaded. Every time 
I (re)connect, AltME offers me to re-download 63 of them. Irrespective 
of whether I re-download or not, I'm again offered this each and 
every time I connect.

It may be the daylight savings time bug, where that changeover makes 
all the file times apparently an hour off. This is because the AltME 
file time handling isn't converted to UTC.

Once a year, go through and redownload every file in the world. And 
be careful to not repost those files, which is hard to do because 
of UI problems.

That only fixes the redownloading, though. (For every changed file 
you want to fetch, you have to download all of them.) In the winter, 
files that you created in the summer will have the wrong status. 
In the summer, files that you created in any winter will have the 
wrong status

there is a config.txt file in same folder with altme.exe but I'm 
not sure if there is an option like that.
there is a line "host-port: 5400" but this is for client.

Did you move one of those worlds to a different port? Are you aware 
that the port number is entered into a configuration file when the 
world is created? If you move it later, you have to edit the configuration 
file. AltME doesn't check for port conflicts on worlds you start

I'm not sure if it's in the server part, but the file sharing is 
kind of weak. I don't know what Carl's plan for Altissimo would be, 
but I can imagine it would be a departure from how AltME works. All 
I really would like to see, is an open source clone of AltME, primarily 
because it's the best messaging/collaboration system, I've ever used.

File sharing bug: Initial comment can only be 100 chars long. Subsequent 
edits can be longer than 100 chars.

- MAJOR ANNOUNCEMENT -  Custom Gob Renderers :  prototype released


After weeks of work at various levels, here is the first prototype 
release of my R3 host-kit running OpenGL in HW.

http://www.pointillistic.com/open-REBOL/moa/files/r3-cgr.zip


I updated it to A109 this week-end, I also completely rebuilt the 
file structure so that all of my tools are outside of the host tree.

only the actual host-code patches remain within the host.  the distribution 
includes compiled versions as well as the latest R2 2.7.7 unreleased 
patch.


note that the current OpenGL CGR is not currently very programmable 
a part from giving it polygons to view, you can't change anything.

the view will rotate by 1 degre everytime you call show or refresh 
on it  (so it can be used for model turntables).

resizing the window resizes the view.   notice that full-screen doesn't 
affect rendering that much.

open the readme file for more information


also note that the current geometry engine auto-calculates surface 
normals using face normals, so you'll have a faceted look.

next release I'll add support for vertex normals which will allow 
smooth shading (at no cost).


please reply in ann-reply, and report any problems you may have... 
I'll fix ASAP.Custom Gob RenderersCustom Gob Renderers

I've had recently the opportunity to dust off my experimental LDAP 
driver code, so I've decided to release it as-is, even if it's unfinished, 
at least querying the server and retrieving data is supported. Download 
at: http://softinnov.org/dl/ldap-protocol.r


The query dialect is probably not working 100%, but at least basic 
queries should do the job. I don't intend to implement more features 
now because I don't have any needs for a LDAP driver, but I'll try 
to fix the query dialect if required by users. I might accept to 
add the missing features and polish it under contracted work or bounty 
(if high enough).

Basic usage syntax and examples can be found in the file header.
Please use Ann-reply group for feedbacks.

I've uploaded my FMOD extension test project to GitHUB:  https://github.com/Oldes/R3-extension-FMOD.

IThis is REBOL3's extension wrapper to FMOD API.

It has command for all 336 FMOD api functions, but 162 of them are 
just placeholders as it require more work.

I must say that this is my first C project which I'm using to learn 
C and REBOL Extensions, so feel free to correct me if you can.


Also I must note, that the main.c file was automaticaly generated 
so it's possible that not everything works, I tested just basics 
so far.

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- added missing images to docs (thanks to Pekr)
- UNVIEW now works like in R2
- removed STYLE/FACED, now it is obsolete (use only STYLE/FACETS)
- improvements to facets creation
- fixed box-model border caclulation
- fixed binding of actors
- DO-STYLE code optimalization and fixes

- VIEW function cleanup, now it should work on block of faces as 
well
- fixed panel(container) names binding
- fixed 'load trigger calling
- fixed WHEN style
- misc smaller fixes
- old unused code cleanup

GLASS RELEASE 002
---------------------------

released last week, but posting it here to make it easier to find, 
since the GLASS group has a lot of discussion in it....

http://www.pointillistic.com/open-REBOL/moa/files/glass-r002.zip


-adds the editor style, which is now able to show text and scroll 
in real-time, but still has no keyboard handling yet.
-adds a few new more advanced tutorials

-adds a new demo app which is the basis for a full text-editor in 
REBOL (you can use the load button which allows you to load text 
within the editor, it loads files almost instantaneously... I was 
surprised how quickly it loaded even 1MB files), file size doesn't 
change editor refresh speed..

very extensive history of changes, 
very extensive TO DO list

some improvements to libs here and there.

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- show-native recursive issue fixed
- enhancements to TEXT-LIST, TEXT-TABLE, TAB-BOX styles
- fixed DO reactor call
- fixed reactor actions handling
- optimized INIT-PANEL function
- added FOREACH-FACE function
- fixed internals of triggers subsystem
- optimized DRAW blocks handling
- optimized DO-STYLE and DO-TRIGGERS code
- added triggers handling to set/insert-panel-content
- lists.r3 code cleanup
- cleanup of unused/leaked variables

------------------------------------------
GLASS Release 003 is here:
------------------------------------------
http://www.pointillistic.com/open-REBOL/moa/files/glass-r003.zip

----------------------------------------------------------
everything promised for this release has been done:
----------------------------------------------------------

-Editor style and associated text editor application (Cristoph)

http://www.pointillistic.com/open-REBOL/moa/files/tutorial-image-style.png


-Encap friendly single file version of ALL glass libs, usable just 
like if they where external files. (Graham)

-The encap version of glass is all packaged within its own .zip file 
inside the root of the distro,  to make it easier to get started.

-Image style (jocko)
-it also has a pretty cool image style demo app.

http://www.pointillistic.com/open-REBOL/moa/files/red-text-editor-v0.5.7.png

-quite a few nuts and bolts worked on here and there.

-reworked the folder structure a bit to make it cleaner (it shouldn't 
change much from now on), tell me what you think?

-Added original SVG files used to create icons as part of distribution

-Added a few reference glass-related images for demos and tutorials.

-windows have automatic title handling when you fill their labels. 
(shown in text editor)
-many libs have had their apis improved
-extensive HISTORY AND RELEASE NOTES in docs folder.

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-updated documentation (though still incomplete)
-complete new set of examples
-new hint based autosizing

-many internal and style related fixes and improvements, for details 
see: http://rm-asset.com/code/level1/r3-gui/#toc1

New RMA release of R3GUI version 2124 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-new set of examples
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2182 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-generic box-model presets
-better text sizing
-improved keyboard navigation
-correct handlind of minimal window size
-cleaned up style tags
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2338 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-new dividers subsystem

-support of application 'shortcut' and 'access' keys (see panels-15.r3 
for details)
-more stable resizing
-improved keyboard handling in some styles
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2367 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:


this is just minor update(as previous one has been published only 
2 days ago) so we(RMA) get back up-to-sync with 'Friday release' 
frequency ;-)


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

----------------------------------------------------------
mod-web-api (v0.5.0)   released !
----------------------------------------------------------
An extensible, programmable webservice module for cheyenne.

http://www.pointillistic.com/open-REBOL/moa/files/mod-web-api-r2.zip

Docs are here, temporarily, until I setup my web server again:

http://www.pointillistic.com/open-REBOL/moa/files/mod-web-api/docs/mod-web-api.html


Installation and setup is all covered in the docs, but in fact, its 
just a question of dropping the file trre right over a cheyenne directory 
tree.
a demo is included as well as a http.cfg file to enable the demo.


it takes 5 minutes to setup and run the demo, as long as you've got 
port 81 free.

is there a way that I can do to pre-allocate a huge file? Pre-allocated 
file will have a continuous disk space, which makes seeking fast.

something like? :

write %file head insert "" 1000000

oops... 

write %file head insert/dup "" " " 1000000

Maxim, I am not sure if doing that will have a continuous disk space. 
Why don't we have something like this: make %file 100000000

Well... I am 95 % sure. By the way, Every column of every table has 
its own one or two huge files. I didn't put all the data in a single 
file.

As far I remember It's working with R2 if you write the %file past 
the end, it's filled with #{00].

I remember having asked the same feature in R3 one year ago at least 
(in the R3 chat)

2 Andreas:  2 ** 26 limit is hardcoded into checksum/hash function 
IMO, this hash function is used for calculating respective key hashes 
in map! datatype I think, nevertheless this hashing is pretty fast 
and could be used in in-file hashes, there the limit can be theoretically 
limiting. But still 2 ** 26 hash table is pretty huge indeed.

Oldes - AFAIK, codecs are going to be completly overhauled. We wanted 
streaming support, and current implementation is imo rather primitive. 
Carl agreed in one roadmap document release, but that file is gone 
(we are waiting for new one). I hope proper port based API will be 
available. So - on one hand it is a good thing it is not part of 
the host-kit, as we arelly need one standardised API, not myriad 
of different hack-ins, but otoh Carl could benefit from some community 
experiments in that regards ....

there were several discussions about the topic. Carl stated, that 
R2 code was very complex, and is willing to provide source for adaptation. 
After some complaint, we got /wait at least. I think that for now 
you have to use call/wait, output to file, and read the file ....

Some *? functions that might be better off as *-OF: ENCODING?, FILE-TYPE?, 
INDEX?, LENGTH?, SIGN? and SIZE?. Except for the first two the old 
names would need to stick around because of the legacy naming rules. 
Strangely enough, UTF? is OK because it is short for "UTF what?". 
The series contents functions have an implicit -OF :)

R3 can't read and write back source file, to correct platform terminators? 
I used such aproach in R3 - just read, and write back to the same 
file. In R3 I even tried read/string, but it does not help when I 
wrote file back ....

Is there a home for R3 one-liners and idioms?


reline: func [file] [write file to-binary enline deline to-string 
read file]

reline: func [file] [write file to-binary enline read/string file]

reline: func [file] [write file enline read/string file]

The advantage to serializing directly in SAVE/all form is speed. 
The disadvantages are:

- The preferences file would be uglier to write by hand than block 
form.

- You would have to screen with ASSERT/type in FOREACH instead of 
PARSE.

Another disadvantage is that loading errors are currently harder 
to recover from with serialized constructors than they are with normal 
literal values like blocks. There's a ticket about this already. 
However, if you are loading the entire preference file in one go 
and just catching the error with TRY, there's no difference in the 
error handling.

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under. It's a way to prevent worms.

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

- I do not have any problem to agree with that. But, in my opinion, 
this does not require to ban files, that are done automatically. 
Rather, we should make it possible to define special rights for such 
files.

as said, for me the formulation: "...a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under..." is substantial, and it can be done, as far as I know.

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

sorry, i don't get that. could you try reformulate the problem?

Andreas, in the OSes with which I am familiar, you can't set a file 
to read-only and then count on that file staying read-only unless 
the user is asked for permission to change that setting. In REBOL 
you can. The security of a DOable %user.r depends on it not being 
writeable between when REBOL shuts down and when it starts up again. 
So that means using OS permissions to guard it, and those are based 
on user capabilities, not enough protection. The situation is different 
with %rebol.r since we only load it from the same location as the 
R3 executable, and that location can be protected with user permissions; 
this is why we can still DO %rebol.r in R3.

you can have a worm spread using a combination of REBOL and code 
that is not written in REBOL but writes %user.r to do its propagation

- yes, you can, but when you run a worm like that, then you are insecure 
anyway, since the worm could overwrite even your rebol.exe file.

And I don't really trust .bashrc for that reason, though there might 
be some OS protection for that file of which I'm not aware.

Ladislav, you can put the rebol.exe file in a place that only admins 
can write to; %rebol.r too. You can't do the same with %user.r.

Andreas, by %user.r, I mean a file that would be loaded from the 
user's home directory or some subdirectory of it (.rebol, %appdata%\REBOL, 
whatever), and which could be manually writeable by the user when 
REBOL isn't running (or else its syntax wouldn't need to be human-readable 
and writeable). If you decide to skip any of those constraints, you 
can secure it despite the limited security models of most the OSes 
we support.

Those are the standard constraints of a preferences file, but there 
are some programs that make exceptions.

Agreed on all points. But if you don't make the file writable without 
having to elevate your permissions first, does that not solve your 
immediate security concern?

I am still having issues with what is considered "secure" here. As 
far as REBOL goes, for me, it is not unsecure, if it relies on the 
user environment being secure. (How can any program be secure, if 
it runs in an insecure environment?) Thus, the only concern I do 
have as far as REBOL goes is my wish for the REBOL interpreter to 
not overwrite the %user.r file unless specifically allowed to do 
that.

The R3 process needs to be able to save the %user.r file with the 
current user's permissions in order to allow the user to save their 
preferences. And we don't have a safe place to store the checksum 
of that file to compare against, without also making that checksum 
writeable by the user. That means that the checksum security can't 
be used for %user.r.

The R3 process needs to be able to save the %user.r file with the 
current user's permissions in order to allow the user to save their 
preferences.

 - this is the only one I find relevant as far as security concerns 
 are considered. Nevertheless, this does not contradict what I said 
 in any way I can imagine.

the whole bitwise thing is pretty fucked up anyway. i tried to do 
a disk editor, a pic microcontroller HEX file processor, a custom 
serial communication protocol and in all cases i had to ping-pong 
between binary! issue! integer! and had to trim to the right bit/byte 
counts. it was a nightmare all the time.

I find myself often needing to sort in a file system on date, when 
the file name contains a date, but I have to manually build a new 
date string, where the month is a zero padded number.


Does it not make sense to have a file-system and sort friendly date 
stamp?

Converting a R2 DLL into a R3 one is really simple. I have done our 
DLLs in a way that I can compile them as R2 or R3 version. The only 
change is a .DEF file for the linker. Everything else is the same.

How can I get a list of all R3 words that are available directly 
after the interpreter booted as input for creating a color coding 
file.

wish for R3 / Topaz / Red / World:

Add possibility to extend "read" and "load" to let them transparently 
load also custom file types (.tiff, .mp3 etc.)
Use something like:
system/mime: context [
	JPG: context [
		extensions: [%.jpg %.jpeg ...]
		header: #{JFIF}
		open: func [...]
		read: func [...]
		load: func [...]
		save: func [...]
		write: func [...]
		close: func [...]
	]
	...
]

When I trace it, it "sees" the error but returns the path:
...
Trace:  return (word)
Trace:  path (word)
Result: (error)
Result: (error)
Result: (error)
Result: %.../ (file)

There is a cross-platform bug in R3 where it won't see any file or 
directory that starts with two periods, not just . and .. - the ticket: 
http://issue.cc/r3/1899

http://commons.wikimedia.org/wiki/File:Paaskerk_Baarn.jpg