This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

REPOST: unlink semantics


With respect to the 'Infinte Loop in "rm -fr"' thread, I believe the current
semantics of unlink on Cygwin to be inconsistent with SuSv2.

SuSv2 specifies the following:
The unlink() function removes a link to a file. If path names a symbolic
link, unlink() removes the symbolic link named by path and does not affect
any file or directory named by the contents of the symbolic link. Otherwise,
unlink() removes the link named by the pathname pointed to by path and
decrements the link count of the file referenced by the link.
When the file's link count becomes 0 and no process has the file open, the
space occupied by the file will be freed and the file will no longer be
accessible. If one or more processes have the file open when the last link
is removed, the link will be removed before unlink() returns, but the
removal of the file contents will be postponed until all references to the
file are closed.

Cygwin's current implementation of unlink is not consistent with the
following part: "If one or more processes have the file open when the last
link is removed, the link will be removed before unlink() returns, but the
removal of the file contents will be postponed until all references to the
file are closed." At present Cygwin delays not only the removal of the file
contents, but also the removal of the link (i.e. the directory entry). This
causes problems with programs that expect the post-condition of unlink to be
that the directory entry for the specified file is removed if unlink returns
0. rm is one example of such a program and this inconsistency is the cause
of the "infinite loop" problem reported in the other thread.
As a suggested fix, path_conv::check could returns ENOENT for a file if it
appears in the delqueue. I would submit a patch for this, but I am not 100%
sure how the delqueue is protected from multiple threads accessing it at the
same time. _readdir would also have to check for a file's presence in the
delqueue.

Chris




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]