Bug of IMFS_unlink ?

[Joel Sherrill]

Wei Shen wrote:
> Hi,
>
> I suspect there is a bug with unlink of IMFS files, but I am not certain.
>
> If a file is still being opened, IMFS_unlink will not really free the
> file node, but just decrements its link count and removes it from the
> parent's chain, and the remaining work is leaved to close.
> memfile_close calls memfile_check_rmnod to delete the file node with a
> zero link count when the last user closes the file.
>
> However, in memfile_check_rmnod "rtems_libio_is_file_open" is checked,
> which it will always be TRUE because the LIBIO_FLAGS_OPEN flag bit has
> not been cleared yet. Hence, the file node will never be deleted,
> while it can no more be accessed in the file system.
>
>   
Can you provide a simple test case and let me analyze it?
> I also wonder why device_close and imfs_dir_close do not do similar
> rmnod checks as memfile_close.
>
>   
Looks to me that the generic close should be detecting this
condition and (maybe) calling the specific filetype for unlink.

What do you think of that?  Again I think it will take a test
case to verify and fix.
> Regards,
> Wei
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985