1748073 Members
5179 Online
108758 Solutions
New Discussion

Allocation Error

 
SOLVED
Go to solution
Jon Pinkley
Honored Contributor

Re: Allocation Error

After more testing, it appears that rename does not fix the backlink, even when renaming to a different name or different directory. My guess is that this is expected behavior, since it is not consisdered the primary link. I.e. the directory pointed to by the backlink does not have an entry with the filename and fileid of the file. So the backlink is not updated.

Analyze disk/repair treats the file as a lost file and puts an entry in [syslost], which doesn't seem to be the correct thing to do, but to avoid that would require that every directory on the disk be searched for an entry with the file id of the file in it.

There doesn't seem to be an easy way to fix the problem using standard utilities. What does work: analyze/disk/repair; set file /remove from target directory, rename from [syslost] to target directory (this updates the backlink because the [syslost] is now the primary entry.

Bottom line: this is a shortcut to avoid if correct backlinks are important to you.

On the other hand, if you are trying to hide files and wnat them to be hard to find, it may be useful.

Jon
it depends
Hein van den Heuvel
Honored Contributor

Re: Allocation Error

Odwillia,

I'm sure you heard more than enough.

There are more, and older discussion on this:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1165943

Just get more space, or use DFU or use an old 'comdir' or such if you can find it.


Jon,

Good catch on the potential backlink issue.
That changes savvy to silly.

The most likely place where folks would actually suffer from a broken backlink is probably
$SHOW ENTRY/FULL
It use the FID -> Name and would fail.
It might report a file as:
_$10$MDA0:[14,4,0]X.COM;1

While this IS a valid DID abbreviated file spec, it will fail because that DID no longer is there.

http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_019.html#index_x_1071

The FID abbreviated name does not provide an alternative as it (un-necesarilly so?!) requires the correct directory even though the FID is unique already. Oddly it does not require a valid leading name character such as the doc implies:

$ dir/nohead/notrail/file/wid=file=40 _$10$MDA0:[a.test]y~[13,3,0].com
_$10$MDA0:[A.TEST]X[13,3,0].COM;1 (13,3,0)
$ dir/nohead/notrail/file/wid=file=40 _$10$MDA0:[a]y~[13,3,0].com
%DIRECT-W-NOFILES, no files found


Anyway... if someone wanted to use this savvy/silly shortcut instead of a proper tool, then the better way to so is:

$create/dir device:[temp]
$set file/enter=[temp] device:[data]*.*;*
$set file/nodir device:[000000]temp.dir
$copy/over device:[000000]temp.dir data.dir !!!
$delete device:[000000]temp.dir;

That is quick and preserves the FID for data.dir.

Yuck...

:-)

Hein.