Mercurial > hg > Members > kono > nitros9-code
view docs/ccguide/unlink.refentry @ 3285:345ff5806dd7
Correct coco.d filename in shipped Defsfile files
It seems that 8 years ago in commit 2624:b8c7b7fbf3c9 the coco defs were put into a
new "coco.d" (from "systype"), and the various level*/<port>/defsfile were updated.
However, the level*/<port>/defs/Defsfile (that are copied to the disk images under
DEFS) were apparently wrongly updated.
author | hpmachining <aur@hpminc.com> |
---|---|
date | Thu, 18 Jun 2020 20:29:32 +0200 |
parents | dc9fb26efbad |
children |
line wrap: on
line source
<!-- Too much inspiration from UNIX version 7 manuals, as you can see: DESCRIPTION Unlink removes the entry for the file pointed to by name from its directory. If this entry was the last link to the file, the contents of the file are freed and the file is destroyed. If, however, the file was open in any process, the actual destruction is delayed until it is closed, even though the directory entry has disappeared. SEE ALSO rm(1), link(2) DIAGNOSTICS Zero is normally returned; -1 indicates that the file does not exist, that its directory cannot be written, or that the file contains pure procedure text that is currently in use. Write permission is not required on the file itself. It is also illegal to unlink a directory (except for the super-user). --> <refentry id="unlink"> <refnamediv> <refname>Unlink</refname> <refpurpose>remove directory entry</refpurpose> </refnamediv> <refsynopsisdiv> <funcsynopsis> <funcprototype> <funcdef><function>unlink</function></funcdef> <paramdef>char *<parameter>fname</parameter></paramdef> </funcprototype> </funcsynopsis> </refsynopsisdiv> <refsect1><title>Assembler Equivalent</title> <para> os9 I$DELETE </para> </refsect1> <refsect1><title>Description</title> <para> Unlink deletes the directory entry whose name is pointed to by "fname". If the entry was the last link to the file, the file itself is deleted and the disc space occupied made available for re-use. If, however the file is open, in any active task, the deletion of the actual file is delayed until the file is closed. </para> </refsect1> <refsect1><title>Diagnostics</title> <para> Zero is returned from a successful call, -1 if the file does not exist, if its directory is write-protected, or cannot be searched, if the file is a non-empty directory or a device. </para> </refsect1> <refsect1><title>See Also</title> <para> OS-9 command "kill" <!-- The original manual referenced link() here, but no such system call exists. --> </para> </refsect1> </refentry>