"Syltrem" writes:

>"JF Mezei" wrote in message
>news:24b16$469e4c87$cef8887a$24343@TEKSAVVY.COM...

>> ANA/DISK/REPAIR will restore those files to the [SYSLOST] directory. But
>> whiles it runs, IO on that disk grinds to a halt.
>>

>It's not in [SYSLOST] as it was purposely deleted
>And yes, I have to do this on Sundays only... or if I can't sleep at 3:00 AM

>Someone else ?

If the files were deleted, I suspect they will be treated the same way as
any other file that was held open while deleted. It lives on the disk but
not in any directory, with a "delete pending" flag. When the (last)
application to hold the file open actually closes it, it will be deleted.
If the system crashes the file will still be there, and $ ANALYZE/DISK
will flag it, and will delete it if /REPAIR is specified.

What I'll guess is the file exists with delete pending set, and will exist
until INSTALL PURGE is executed, or the system is shut down cleanly (which
does an INSTALL PURGE). I suggest:

1) Don't worry about it.
2) Reboot the system if 1) doesn't work for you.
3) If the system crashes without shutting down cleanly, do an
$ANALYZE/DISK/REPAIR to get rid of it after the system reboots.

Syltrem wrote:
> But still, I cannot do it as all hell will break loose in my applications.
> I'd rather do a shutdown.


Would it be possible to do a SET FILE/ENTER based on the file-id of the
"lost" files ? Then you would have a bona-fide pointer to a file and
could then use "install delete" to remove that installed image, and then
do a proper delete on the file.

If you had caught this early enough, you might have been able to use an
undelete utility (included in DFU) to restore the deleted directory file
at which point, you'd have fixed the problem.

You can still try it. The old directory file might still be recovable.

Another option you might have is to recreate a new directory of the same
name, and create a new version of the executable, and then use INSTALL
REPLACE, and this could free up the ghost installed image.

JF Mezei wrote:
> Syltrem wrote:
>
>> But still, I cannot do it as all hell will break loose in my
>> applications. I'd rather do a shutdown.
>
>
>
> Would it be possible to do a SET FILE/ENTER based on the file-id of the
> "lost" files ? Then you would have a bona-fide pointer to a file and
> could then use "install delete" to remove that installed image, and then
> do a proper delete on the file.
>
> If you had caught this early enough, you might have been able to use an
> undelete utility (included in DFU) to restore the deleted directory file
> at which point, you'd have fixed the problem.
>
> You can still try it. The old directory file might still be recovable.
>
> Another option you might have is to recreate a new directory of the same
> name, and create a new version of the executable, and then use INSTALL
> REPLACE, and this could free up the ghost installed image.

Was the directory deleted, or the contents of the directory deleted, or
both? If the directory was deleted (shouldn't be possible without first
set file/remove or deleting all the files in it), then ana/disk/repair
should put the files in [syslost]. Do you have sufficient privileges
to do this (you would need at least write access to [000000] on the disk,
or BYPASS, IIRC.)

If the files are deleted, then because they are marked for delete, I think
ANA/DISK/REP will ignore them, and wait for them to go away when they
are closed (when the "open count" goes to zero, which for installed images
won't happen until they are removed and no process has them mapped.) If
the system crashes or the disk is improperly dismounted in the interim
(for example, it goes offline and then into mount verify timeout), I
think you'll have to wait for a reboot, and then ana/disk/repair to make
them go away, but in this case, they'll just be taking up space; after
the reboot, the system won't know about them as installed images any more.

Have you checked if DFU's undelete function will bring them back? Since
they are installed, the blocks they are using on the disk and their headers
are safe from re-use, they just have a delete-pending bit set in memory
somewhere and in their headers, and they are no longer entered in any
directory. If DFU can clean up the delete-pending bits, ana/disk/repair
should put them in [syslost], and then you can create (or recreate) the
directory and rename them from [syslost] to [desired_directory], thus
restoring the system state.

Are they read-only shareable images (typical of executables or runtime
libraries), in which case retrieving them from your backups would be
fine, and you could let things continue to run indefinitely with existing
processes using the deleted copies and any new processes using the restored
copies. Or are they read/write (shared data sections), in which case
you probably want the data back? If worst came to worst, you could
track down the headers, dump out the retrieval pointers, and then
DUMP/BLOCK=(start=x,count=y) DISK: to get back the contents (depending
on how dynamic the data is.) Then a SMOP on the dump file to convert back to
binary and Bob's your uncle. Then think about your backup procedures
and user privileges and protection codes on files and directories to
prevent this from happening again and to make it easier to recover!


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

Syltrem wrote:
>
> Hello JF
>
> "JF Mezei" wrote in message
> news:24b16$469e4c87$cef8887a$24343@TEKSAVVY.COM...
>
> >
> > Tisk Tisk ! No chocolate for you today :-)
>
> :-(
>
> >
> > ANA/DISK/REPAIR will restore those files to the [SYSLOST] directory. But
> > whiles it runs, IO on that disk grinds to a halt.
> >
>
> It's not in [SYSLOST] as it was purposely deleted

VERIFY (ANALYZE/DISK/REPAIR) should create a new one and enter those files into
it. That may or may not fix your problem.

> And yes, I have to do this on Sundays only... or if I can't sleep at 3:00 AM
>
> >
> > To "uninstall" the images, you can try:
> >
> > $INSTALL PURGE
> >
> > This ininstalls all installed files from that node, on all disks where
> > there are installed images, global sections and what not.
> >
> >
>
> I did't know this.
> But still, I cannot do it as all hell will break loose in my applications.

Why?

> I'd rather do a shutdown.

Sounds good to me. Shutdown the app., do the INSTALL PURGE, the
ANAL/DISK/REPAIR. Then, see what state things are in.

A reboot wouldn't hurt, but not until you've done the above.

In any case, I do hope you have a backup with these files on it somewhere...

--
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

In article <139sni13ldd6m91@corp.supernews.com>,
"Syltrem" wrote:

> OVMS 8.3 Alpha or IA64

> Someone else ?

OVMS 8.3 Alpha here.

$ Directory DKA0:

HELLO.C;1 HELLO.EXE;1 HELLO.OBJ;1

Total of 3 files.

$ install add disk$alphasys:[temp]hello.exe/open/shared
$ del dka0:*.*.*/lo
%DELETE-I-FILDEL, DKA0:HELLO.C;1 deleted (18 blocks)
%DELETE-I-FILDEL, DKA0:HELLO.EXE;1 deleted (18 blocks)
%DELETE-I-FILDEL, DKA0:HELLO.OBJ;1 deleted (18 blocks)
%DELETE-I-TOTAL, 3 files deleted (54 blocks)

$ install lis disk$alphasys:[temp]hello.exe/fu

DISK$ALPHASYS:.EXE
HELLO;1 Open Shared
Entry access count = 0
Current / Maximum shared = 1 / 0
Global section count = 1

$ install del disk$alphasys:[temp]hello.exe
$

IOW, V8.3 doesn't seem to care if the original .EXE actually exists
anymore.

Note that it can be picky about the device name. For example, if added
using DKA0:, the listing shows DISK$ALPHASYS, but that doesn't work for
the delete:

$ cre/dir dka0:
$ copy hello.* dka0:/lo
%COPY-S-COPIED, USER_SY:HELLO.C;1 copied to
DKA0:HELLO.C;1 (1 block)
%COPY-S-COPIED, USER_SY:HELLO.EXE;1 copied to
DKA0:HELLO.EXE;1 (7 blocks)
%COPY-S-COPIED, USER_SY:HELLO.OBJ;1 copied to
DKA0:HELLO.OBJ;1 (4 blocks)
%COPY-S-NEWFILES, 3 files created
$ install add dka0:hello.exe/open/share/head
$ install list dka0:hello.exe /full

DISK$ALPHASYS:.EXE
HELLO;1 Open Hdr Shared
Entry access count = 0
Current / Maximum shared = 1 / 0
Global section count = 1

$ install del DISK$ALPHASYS:HELLO.EXE
%INSTALL-W-FAIL, failed to REMOVE entry for DISK$ALPHASYS:HELLO.EXE
-INSTALL-E-NOKFEFND, Known File Entry not found
$ install del DKA0:HELLO.EXE
$

A little bit of trial and error will probably get you there.

--
Paul Sture

"P. Sture" wrote in message
newsaul.sture.nospam-02DD5A.13541919072007@mac.sture.ch...
> In article <139sni13ldd6m91@corp.supernews.com>,
> "Syltrem" wrote:
>
>> OVMS 8.3 Alpha or IA64
>
>> Someone else ?
>
> OVMS 8.3 Alpha here.
>
> $ Directory DKA0:
>
> HELLO.C;1 HELLO.EXE;1 HELLO.OBJ;1
>
> Total of 3 files.
>
> $ install add disk$alphasys:[temp]hello.exe/open/shared
> $ del dka0:*.*.*/lo
> %DELETE-I-FILDEL, DKA0:HELLO.C;1 deleted (18 blocks)
> %DELETE-I-FILDEL, DKA0:HELLO.EXE;1 deleted (18 blocks)
> %DELETE-I-FILDEL, DKA0:HELLO.OBJ;1 deleted (18 blocks)
> %DELETE-I-TOTAL, 3 files deleted (54 blocks)
>
> $ install lis disk$alphasys:[temp]hello.exe/fu
>
> DISK$ALPHASYS:.EXE
> HELLO;1 Open Shared
> Entry access count = 0
> Current / Maximum shared = 1 / 0
> Global section count = 1
>
> $ install del disk$alphasys:[temp]hello.exe
> $
>


Hmm, yes, but the directory was not deleted
I tried on my test system and even with the directory deleted, it still
works.
Great!

So I just need to remember what the name of the directory was.
Those are not files that I need; I just forgot to INSTALL REMOVE before
deleting the directory.

I remember the name of one of the 2 directories I'm having problems with. I
was able to successfully remove the entries from it. The other one is a bit
deeper (many levels) so I will just do a backup/list of a tape that has it
to find the correct path to the installed files.

Why I cannot INSTALL PURGE, I was asked ?
Because "protected images must be installed" (can`t remember the exact
message I would get, would I try this).
If I could stop my applications and uninstall them, I could do a shutdown as
well. But I can`t.

Thanks very much for your help, everyone !

Problem solved without a reboot (of course, this is not M$) !

Syltrem

"Syltrem" wrote in message
news:139uu4h7mjbtmc0@corp.supernews.com...

> I remember the name of one of the 2 directories I'm having problems with. I was able to
> successfully remove the entries from it. The other one is a bit deeper (many levels) so
> I will just do a backup/list of a tape that has it to find the correct path to the
> installed files.

"pipe install list > files.txt" might be quicker than messing around with tapes.

"Richard Brodie" wrote in message
news:f7nuhc$sde$1@south.jnrs.ja.net...
>
> "Syltrem" wrote in message
> news:139uu4h7mjbtmc0@corp.supernews.com...
>
>> I remember the name of one of the 2 directories I'm having problems with.
>> I was able to successfully remove the entries from it. The other one is a
>> bit deeper (many levels) so I will just do a backup/list of a tape that
>> has it to find the correct path to the installed files.
>
> "pipe install list > files.txt" might be quicker than messing around with
> tapes.
>
>

Install LIST gives the path as [43456,0,0]
That's the whole point...

Syltrem

P. Sture wrote:
> $ install add disk$alphasys:[temp]hello.exe/open/shared
> $ del dka0:*.*.*/lo
> %DELETE-I-FILDEL, DKA0:HELLO.C;1 deleted (18 blocks)
> %DELETE-I-FILDEL, DKA0:HELLO.EXE;1 deleted (18 blocks)
> %DELETE-I-FILDEL, DKA0:HELLO.OBJ;1 deleted (18 blocks)
> %DELETE-I-TOTAL, 3 files deleted (54 blocks)


As I recall, he didn't delete the .EXE, he deleted TEMP.DIR

"JF Mezei" wrote in message
news:b17f3$469f9821$cef8887a$26546@TEKSAVVY.COM...
> P. Sture wrote:
>> $ install add disk$alphasys:[temp]hello.exe/open/shared
>> $ del dka0:*.*.*/lo %DELETE-I-FILDEL, DKA0:HELLO.C;1 deleted
>> (18 blocks)
>> %DELETE-I-FILDEL, DKA0:HELLO.EXE;1 deleted (18 blocks)
>> %DELETE-I-FILDEL, DKA0:HELLO.OBJ;1 deleted (18 blocks)
>> %DELETE-I-TOTAL, 3 files deleted (54 blocks)
>
>
> As I recall, he didn't delete the .EXE, he deleted TEMP.DIR

Hi JF
I deleted both, but that still works. See my other post !

Syltrem

On Jul 18, 8:11 pm, John Santos wrote:
> JF Mezei wrote:
> > Syltrem wrote:
>
[...]
>
> Have you checked if DFU's undelete function will bring them back? Since
> they are installed, the blocks they are using on the disk and their headers
> are safe from re-use, they just have a delete-pending bit set in memory
> somewhere and in their headers, and they are no longer entered in any
> directory. If DFU can clean up the delete-pending bits, ana/disk/repair
> should put them in [syslost], and then you can create (or recreate) the
> directory and rename them from [syslost] to [desired_directory], thus
> restoring the system state.
[...]
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539- Hide quoted text -
>
> - Show quoted text -

I thought it must have come up before as I'm using DFU 2.4, 2.6, and
2.7-A, but I better mention it now: DFU's UNDELETE function clobbered
other files when I used it! I got ANAL/DISK messages like this one:

%ANALDISK-W-BADDIRENT, invalid file identification in directory entry
[SYS0.SYSCOMMON.SYSMGR]PORT.COM;7
-ANALDISK-I-BAD_DIRFIDSEQ, invalid file sequence number in directory
file ID

I'd try it on a scratch disk first.

Has anyone else had this problem with DFU?

AEF

In article <139v84cm2khp646@corp.supernews.com>,
"Syltrem" wrote:

> "JF Mezei" wrote in message
> news:b17f3$469f9821$cef8887a$26546@TEKSAVVY.COM...
> > P. Sture wrote:
> >> $ install add disk$alphasys:[temp]hello.exe/open/shared
> >> $ del dka0:*.*.*/lo %DELETE-I-FILDEL, DKA0:HELLO.C;1 deleted
> >> (18 blocks)
> >> %DELETE-I-FILDEL, DKA0:HELLO.EXE;1 deleted (18 blocks)
> >> %DELETE-I-FILDEL, DKA0:HELLO.OBJ;1 deleted (18 blocks)
> >> %DELETE-I-TOTAL, 3 files deleted (54 blocks)
> >
> >
> > As I recall, he didn't delete the .EXE, he deleted TEMP.DIR
>
> Hi JF
> I deleted both, but that still works. See my other post !
>

In fact I also deleted the directory. I just forgot to paste that bit
into my reply.

--
Paul Sture

AEF wrote:

> I thought it must have come up before as I'm using DFU 2.4, 2.6, and
> 2.7-A
.....
> Has anyone else had this problem with DFU?

Older DFU had its share of bugs.

You're way back, too.

DFU V3.1-1 and V3.2 are current.

http://www.digiater.nl/dfu
http://64.223.189.234/node/58


--
www.HoffmanLabs.com
Services for OpenVMS

On Jul 20, 12:45 pm, Stephen Hoffman RemoveThis-.Org> wrote:
> AEF wrote:
> > I thought it must have come up before as I'm using DFU 2.4, 2.6, and
> > 2.7-A
> ....
> > Has anyone else had this problem with DFU?
>
> Older DFU had its share of bugs.
>
> You're way back, too.
>
> DFU V3.1-1 and V3.2 are current.
>
> http://www.digiater.nl/dfuhttp://64.223.189.234/node/58
>
> --www.HoffmanLabs.com
> Services for OpenVMS

It's kind of ironic, no? You use UNDELETE and it secretly deletes
other perfectly good files! Then you need to UNDELETE those! Etc. ...
Yikes!

AEF

AEF wrote:
>
> On Jul 18, 8:11 pm, John Santos wrote:
> > JF Mezei wrote:
> > > Syltrem wrote:
> >
> [...]
> >
> > Have you checked if DFU's undelete function will bring them back? Since
> > they are installed, the blocks they are using on the disk and their headers
> > are safe from re-use, they just have a delete-pending bit set in memory
> > somewhere and in their headers, and they are no longer entered in any
> > directory. If DFU can clean up the delete-pending bits, ana/disk/repair
> > should put them in [syslost], and then you can create (or recreate) the
> > directory and rename them from [syslost] to [desired_directory], thus
> > restoring the system state.
> [...]
> > --
> > John Santos
> > Evans Griffiths & Hart, Inc.
> > 781-861-0670 ext 539- Hide quoted text -
> >
> > - Show quoted text -
>
> I thought it must have come up before as I'm using DFU 2.4, 2.6, and
> 2.7-A, but I better mention it now: DFU's UNDELETE function clobbered
> other files when I used it! I got ANAL/DISK messages like this one:
>
> %ANALDISK-W-BADDIRENT, invalid file identification in directory entry
> [SYS0.SYSCOMMON.SYSMGR]PORT.COM;7
> -ANALDISK-I-BAD_DIRFIDSEQ, invalid file sequence number in directory
> file ID
>
> I'd try it on a scratch disk first.
>
> Has anyone else had this problem with DFU?

I think it's a known caveat: when doing any such things - UNDELETE, DELETE/TREE,
etc. - the recommendation is to first quiesce the system.

Best advice: DISMOUNT the volume from the system and MOUNT it privately so you
can be 100% certain that DFU has entirely exclusive access.

Note also that DFU V2.7 or so DELETE/TREE cannot handle huge file counts in a
tree without issues.

--
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

On Jul 21, 11:32 am, David J Dachtera
wrote:
> AEF wrote:
>
> > On Jul 18, 8:11 pm, John Santos wrote:
> > > JF Mezei wrote:
> > > > Syltrem wrote:
>
> > [...]
>
[...]
> > > - Show quoted text -
>
> > I thought it must have come up before as I'm using DFU 2.4, 2.6, and
> > 2.7-A, but I better mention it now: DFU's UNDELETE function clobbered
> > other files when I used it! I got ANAL/DISK messages like this one:
>
> > %ANALDISK-W-BADDIRENT, invalid file identification in directory entry
> > [SYS0.SYSCOMMON.SYSMGR]PORT.COM;7
> > -ANALDISK-I-BAD_DIRFIDSEQ, invalid file sequence number in directory
> > file ID
>
> > I'd try it on a scratch disk first.
>
> > Has anyone else had this problem with DFU?
>
> I think it's a known caveat: when doing any such things - UNDELETE, DELETE/TREE,
> etc. - the recommendation is to first quiesce the system.

Known to whom? Those who already got burned?

> Best advice: DISMOUNT the volume from the system and MOUNT it privately so you
> can be 100% certain that DFU has entirely exclusive access.

When this happened I restored the most recent backup tape of the disk
to a fresh disk on another system. I mounted it privately and repeated
the same goof and UNDELETE command.

Same results. So it has nothing to do with exclusive access. DFU locks
the volume anyway during UNDELETE.

>----O----<

I forgot to mention I also got messages like this:

%ANALDISK-W-ALLOCCLR, blocks incorrectly marked allocated
LBN 421880 to 421883, RVN 1

>----O----<

Also, the doc says (V2.4)

NOTE: The volume (set) will be locked for other users during the
undelete command unless the /LIST qualifier is used.

The UNDELETE command may be able to recover the file if it has not yet
been overwritten with a new one. Much care has been taken to make this
command as safe as possible; therefore no disk corruptions will be the
result of an UNDELETE. If DFU encounters a problem with a deleted file
it will refuse to UNDELETE it.

>----O----<

OK: What I don't understand is why it messed with the the file
sequence numbers in the file headers of other files.

> Note also that DFU V2.7 or so DELETE/TREE cannot handle huge file counts in a
> tree without issues.

Now he tells me! :-)

Anyway, I haven't used DFU UNDELETE since!

>
> --
> David J Dachtera
[...]

AEF

On Jul 20, 12:45 pm, Stephen Hoffman RemoveThis-.Org> wrote:
> AEF wrote:
> > I thought it must have come up before as I'm using DFU 2.4, 2.6, and
> > 2.7-A
> ....
> > Has anyone else had this problem with DFU?
>
> Older DFU had its share of bugs.
>
> You're way back, too.
>
> DFU V3.1-1 and V3.2 are current.
>
> http://www.digiater.nl/dfuhttp://64.223.189.234/node/58
>
> --www.HoffmanLabs.com
> Services for OpenVMS

I'm running VMS V6.1 and V6.2. I believe I can't use those current
versions.

Thanks anyway.

AEF