Skip to Main Content
IBM Power Ideas Portal

This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Created by Guest
Created on Feb 21, 2018

Error state if unix function write() writes into a deleted file

1. A Programm writes a large IFS-File.
2. An automated FTP-Job copies this file and the file is deleted.
3. The Programm writes und the unix-Api write() returns only the bufferlen of the bytes writen. The missing file is ignored.

A state -1 should be returned by a write operation, which has ended with an error. The open() returns also -1, if there is an error

Use Case:

A booking history file (50 Millions of records) should transfered to a pc-system --> long running program.
A ftp file copies and deletes the file, wether the file is already written. During the program- and fileopening is no possibility to lock the fileobject against deletion.

Idea priority Low
  • Guest
    Feb 23, 2018

    This is working as designed and part of the POSIX specification and will not be changed. Many applications expect this behavior and use these opened and unlinked files as application working storage that they know will get cleaned up when the descriptor closes.

    An unlink() or RMVLNK function will only remove the link from the directory so you cannot find the path, it may not actually delete the object. The storage of the object will be freed only if it is the last link AND there are no open descriptors to it. In other words, if there are other hard links to the object OR if there is an open descriptor to the file, the object continues to exist.

    The POSIX specification for unlink() states:
    "When the file's link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed."

    This is exactly the behavior of the root, QOpenSys, and user-defined file systems.
    The Knowledge Center documentation for unlink() states:
    "The unlink() function removes a directory entry that refers to a file. This unlink() deletes the link named by path and decrements the link count for the file itself.

    If the link count becomes zero and no job currently has the file open, the file itself is deleted. The space occupied by the file is freed for new use, and the current contents of the file are lost. If one or more jobs have the file open when the last link is removed, unlink() removes the link, but the file itself is not removed until the last job closes the file."

    In order to prevent the unlink to be performed at all or prematurely there are ways to do that. If it is an errant unlink and it normally shouldn't be unlinked, then you can lock it down. If this was just a timing problem that the writes didn't complete as expected, then you need to make sure the different jobs communicate so that functions happen in the correct order.

    1. Create some synchronization object. Get the lock, open the file, write all the data, close the file, release the lock. Then in the ftp job, get the lock (will block until released in the other job), then perform the copy and unlink.
    2. The CHKOUT command could be used to check out a file so that only the user profile performing the checkout could unlink the file or make any updates to the content of the file. Only the checkout user or a user with special authority could check the object back in.
    3. Set the "restricted rename and unlink" attribute for the parent directory. This makes it so that only the owner of the object, the owner of the object's parent directory, or someone with *ALLOBJ special authority can unlink it, regardless of any other authorities to the object.
    4. Add a second link to the object so you can relink the file with the original link and call the ftp job again if it gets unlinked prematurely.
    For example:
    The file being used is: /dir1/myfile
    Add another hard link to it through a path that has restricted access.
    ADDLNK OBJ('/dir1/myfile') NEWLNK('/securedir/myfile') LNKTYPE(*HARD)
    The functions can run as they are. If you find that /dir1/myfile was unlinked prematurely, you can add the link back:
    ADDLNK OBJ('/securedir/myfile') NEWLNK('/dir1/myfile') LNKTYPE(*HARD)
    Run the ftp job again which will unlink /dir1/myfile
    Then unlink /securedir/myfile.

  • Guest
    Feb 21, 2018

    Attachment (Use case): Savefile with sample program