OpenSolaris

Printable Version Enter a New Search
Bug ID 6581318
Synopsis consider to bury link(2)/unlink(2) support for directories in UFS
State 4-Defer:No Resource Available (Accepted, but the fix may not be made soon.)
Category:Subcategory kernel:ufs
Keywords ufs-cleanup
Reported Against snv_67
Duplicate Of
Introduced In
Commit to Fix
Fixed In
Release Fixed
Related Bugs 6274230 , 6343621 , 4019154 , 4073084 , 4369688 , 4386111 , 4386299 , 4847243 , 4975493 , 6500142 , 6653509 , 6802380 , 4917742 , 4879767 , 5034108
Submit Date 17-July-2007
Last Update Date 18-July-2007
Description
this is a request to consider to bury link(2)/unlink(2) support 
for directories in UFS

as we all know if a process with appropriate privilidges executes unlink(2)
on a directory, things like ".." (and the link count in the parent) 
would not be cleaned up. this leads to orphaned directories requiring fsck's attention.

for the gory details that explain the pure existance and standard requirements
and implications of this behavior see 4917742

this came up just recently on opensolaris once again and we discussed some
escape route with Casper in it:

http://www.opensolaris.org/jive/thread.jspa?messageID=80961

Linus GIT revision control system also caught this in the act on Solaris:

http://article.gmane.org/gmane.comp.version-control.git/52654

is there a chance we can manage to get rid of it without getting into much hassle
as far as the standard is concerned ?
at least via a new mount option for UFS if not just remving the implementation of it?

You know, people just do not get rmdir(2/1).
Work Around
just use rmdir(1/2)

or use ZFS 

*** (#1 of 1): [ UNSAVED ]  xxxxx@xxxxx.com
Comments
N/A