Re: colon in item id to DOS directory
- From: "Chandru Murthi" <cmur_xyz_thi@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 04 Sep 2006 21:30:45 GMT
"Tony Gravagno" <g6q3x9lu53001@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2qsnf291fva3pdj2qjtmoif518kppirpa1@xxxxxxxxxx
Don't worry about damage to NTFS. What's happening underneath is that
Windows is simply rejecting the file update. It's just that D3 isn't
passing an error back up to you.
<setup>
The BASIC WRITE statement executes without error whether or not the
item was written. In traditional R83 and pre-OSFI days there was no
such thing as remote file system, so if a WRITE failed, chances are
you got one or more "&" ampersand signs, which told you there was a
disk error. These days we can open a file across the network or to a
host OS file system, but if the network drops or the file is read-only
(typical error for Linux when not running as root), disk write
operations from BASIC have no way to inform us of failure. So many
years ago I requested enhancements to BASIC statements which perform
disk write, to return an error when the update failed.</>
In D3 v7.5, BASIC statements that perform updates now include an
"on.error.clause" which traps when disk updates from BASIC fail. This
was requested for all file update statements, and (bless their hearts)
they got WRITE and DELETE, but it looks like they missed CLEARFILE,
MATWRITE, WRITEVU, and maybe some others. I don't know if it works
properly, there were no docs on this for the v7.5 beta, no clue about
what to expect on various types of errors, no examples of actual
syntax. I don't know if it can report what happened on error, whether
"reserved character" errors like what's reported by the host OS, or
"permissions error", or unable to connect to network, etc.
Agreed, it is definitely impossible to send back a specific error message.
It may or
may not catch your KILROY:WASHERE issue. (Though I have to wonder
what you really expected by trying that.)
To work, perhaps, a quaint notion we oldsters expect.
Far as I know, uv does not have any restrictions on the id, certainly it'll
accept : * and others the native OS would not. Hmm...wonder how they did
that...ah yes, it's coming back...could it be there's such a thing as an
escape character? and could it be that once again RD systems design is
exposed as...oops...that's not productive, is it?
What the heck. Since OSFI is supposedly a replacement of the original file
system, which did not have any id restrictions, this is just brain-dead. If
they'd been dealing with 8-char id limits as on pre-Win whatever, would
that have failed too? And yes, I, and most others, could have programmed it
so it works right.
Chandru Murthi
It may be fully implemented
in the production cut along with the docs, I haven't loaded the
production v7.5 release. If this is of use to anyone, give it a shot
and let us in CDP land (and RD) know how it works for you.
As far as access from TCL, ED, etc, I sort of doubt that they are
returning any more errors for OSFI updates in v7.5 than they did
before. I'm pessimistic about people's ability to connect dots like
that : "hey, if BASIC reports an error, maybe other file update
methods should too?" I hope I'm wrong.
T
Jeremy wrote:
I wondered where my audit items were disappearing to then I noticed
their item-ids had a colon ":" in them and the audit file was a Q
pointer to a DOS directory.
Interesting behaviour when this happens.
You end of with a 0 byte DOS file with the file name being the itemid
before the colon.
You can still access the items in D3, though you cant select or list
them.
Deleting an item with a colon in the id of a DOS directory leaves the 0
byte file of the items id before the colon.
e.g.
Say AUDIT is a super-Q pointer to a DOS directory.
Q
C:/d3audit
I Edit an item
:ED AUDIT KILROY:WASHERE
new item
top
.I
001+ www
002+ (o o)
003+--oOO(_)OOo--
004+
top
.FI
[221] 'KILROY:WASHERE' filed.
:LIST AUDIT
Page 1 AUDIT.RS
AUDIT
KILROY
When I list the directory in Windows just the file "KILROY" shows with
0 bytes.
:select audit = 'KILROY:WASHERE'
[401] no items present.
:ED AUDIT KILROY:WASHERE
top
.P
001 www
002 (o o)
003 --oOO(_)OOo--
eoi 003
.EX
[220] 'KILROY:WASHERE' exited
:DELETE AUDIT KILROY:WASHERE
[435] Item 'KILROY:WASHERE' deleted
:LIST AUDIT
Page 1 AUDIT
AUDIT
KILROY
Again listing the directory in Windows shows the "KILROY" file 0 bytes.
I'm wondering if I'm doing any damge to NTFS with these files.
I guess D3 is assigning the space to store the files from Windows but
windows doesnt know about the file. Certainly the directory is
disconnected to the 'real' file.
Jeremy Thomson
.
- Follow-Ups:
- Re: colon in item id to DOS directory
- From: Bill H
- Re: colon in item id to DOS directory
- From: Pickie
- Re: colon in item id to DOS directory
- References:
- colon in item id to DOS directory
- From: panzerboy
- colon in item id to DOS directory
- Prev by Date: Re: colon in item id to DOS directory
- Next by Date: Re: SYSTEM(14) with D3
- Previous by thread: Re: colon in item id to DOS directory
- Next by thread: Re: colon in item id to DOS directory
- Index(es):
Relevant Pages
|
