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
ELETE 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

Jeremy,

I would suggest "don't do that". If you are using the OSFI, you need to
abide by the "rules" of the underlying operating system ... other
characters to avoid would include "/" (on *nix) and "\" (on Windows)
.... even a "space" can be bad news!

making some assumptions based on your filename, I'm going to guess you
have a audit file for changes and you are including a TIMDATE() stamp?
Just amend you audit routine so that spaces, ":" and "/" are converted
to, say "-" .... if the data is part of a key you are auditing,
consider amending your structure so that an audit record is written as
@ID:@FM:@REC .... extract @ID then do a REMOVE to restore original
record image


panzerboy (AT) gmail (DOT) com wrote:

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. It may or
may not catch your KILROY:WASHERE issue. (Though I have to wonder
what you really expected by trying that.) 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:

Jeremy:

This is a generalized problem when writing anything from within an MV dbms
to a Unix or Windows directory. There are O/S restrictions regarding what
characters can be used in the "filenames".

Google these restrictions and don't write anything to the O/S files using
those restricted characters in the filenames.

Hope this helps.

Bill

P.S. You'll have the same problems when copying MV dbms records to the O/S
for transfer purposes.

<panzerboy (AT) gmail (DOT) com> wrote

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Agreed, it is definitely impossible to send back a specific error message.

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

Tony Gravagno wrote:
No the file is not rejected, its is written... somewhere.
I can ED the item from D3 (or READ in BASIC), the file doesnt show in
Windows or in a LIST. Thus I get a truncated item id as the file name
in Windows which is 0 bytes long. The space to put the file into must
be reserved from Windows somehow, but it doesnt have a directory entry
to point to the sectors on the disk where the file data is.
I Guess I'm worried about Cross-linked clusters & the sorts of errors
that used to come up doing CHKDSK. Dont know if that stuff still
applies running NTFS type file system.

....> It may or
involve showing item-ids with client names that they may not appreciate
becoming planetary knowledge.

Heres the bit where I can ED the item, thus the file has been saved
somwhere in windows.

R83 could fail a write from a very long time ago - remember the
update/retrieval locks? I never understood why it wasn't possible to
catch this in the application code. Anyone have an idea why? Or was
there some way to do this that I never spotted in the manual?

Jeremy wrote:
Interesting challenge! I missed the point that you could actually
read the data back. I've reproduced your scenario by saving data into
c:\temp\weird "foo:bar". I can easily edit and list-item on items
like this, but a List or Sort verb, not surprisingly, doesn't show the
items. I dumped every frame in my VME and scanned every item in the
FSI but I can't find the data in there. I shutdown and rebooted, and
it's there as expected. I haven't run a low level scan on my C drive,
but a deep scan through the entire drive doesn't find the item text in
the normal file system. Chkdsk is clean.

My guess is that they are using a function for writing to the file
system which somehow (maybe through a bug) allows them to write using
reserved characters. (CreateFile()? _open? no clue) Because the ID
isn't valid to Windows, the Windows Explorer program (which is just
another program, not some special disk scanning tool) can't see the
file. Some special utility that scans the file system might find the
pointers. (I'm pretty clueless in this area.) If this is the case,
as long as the D3 OSFI driver can r/w from disk, then I suppose it's
OK to write all you want as long as you delete everything behind you.

As you suspected, if you do a backup of Windows, that data will
probably not be saved. If you delete the directory from Windows it's
a 50/50 shot as to whether the disk space would be lost - it depends
on what the delete mechanism is doing underneath.

Bottom line is really to not play games like this. Run your item ID's
through a munging routine that only uses valid ID's, and ensure that
you get a unique ID for every invalid ID. This is easy to do. If you
consider this to be a bug, ask your VAR to file an action item with
RD.

I'm curious and interested, but I can't spend any more time on this.
If you find the solution please let us know. Hint: One phone call or
email to RD should get a solid answer.

Tony

"Chandru Murthi" wrote:

You're confusing OSFI with FSI - two completely different things.
Honest mistake.

That said, from his more recent post it sounds like there is another
error somewhere... see other post.

T

Chandru:

As a side note, I should mention that when copying UV data to an O/S
directory the item IDs (filenames) are actually modified by replacing
unacceptable characters with others UV can then untranslate when copying the
same items back into UV. This didn't work too well when copying items from
UV to UD though. :-(

"Chandru Murthi" <cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote ...

[snipped]

This does appear to be a quaint notion! I'm constantly amazed with the
amount of software and hardware that simply don't work. Whenever we build
solutions we're always having to include various hardware and software as
part of the solution. By doing this we're always faced with the 95% rule
(things work 95% of the time). So, when we introduce several 95% components
we find the maintenance and support costs go up dramatically. Thus, each
solution needs a babysitter (to one degree or another) to make sure stuff
works. :-)

Bill