Dosfs question..?

Eugeny S. Mints emints at ru.mvista.com
Thu Nov 18 18:02:23 UTC 2004


Thomas,

Thomas Doerfler wrote:
> Daniel, Jennifer,
> 
> this seems like a bug to me. I have looked into "unlink()" code, 
> and currently I really don't understand, why unlink tries to 
> evalute the permissions of the parent of the current directory. 
> 
> When I want to delete the file "/mnt/ramdisk0/testfile.txt", it 
> makes sense to check the permissions of "testfile.txt" and of 
> "/mnt/ramdisk0", because if any of these two is not writable, a 
> delete would be illegal. But why check "/mnt" ?
it is definitly something wrong some where but it seems to me that 
unlink() just checks permissions for the file you are going to delete 
and the directory which contains this file, i.e. file1 and ramdisk0 , 
and this seems reasonable.
Probably the core of the issue is that FAT root dir doesn't contain ".." 
entry, I'm thinking over this....

Oops, seems found the bug in msdos eval code. The handling of ".." case 
in FAT root dir is right the next operation after the "if" statement 
which returns the error for Daniel.

Daniel, please try to exchange these two "if"s and see what happen.
(Unfortunately I have no up-to-date RTEMS sources in the hands).

	Eugeny
> 
> Does unlink check the wrong directory? Or does 
> "rtems_filesystem_evalute_parent" check the wrong directory? 
> Currently I don't think that the MSDOS implementation is wrong 
> here, although there is no "." or ".." directory entry in its 
> root.
> 
> Jennifer, can you help here?
> 
> wkr,
> Thomas.
> 
> 
> 
>> 
>>-- In unlink()
>>
>>Rtems_filesystem_evaluate_path() returns fine.
>>Rtems_filesystem_evaluate_parent() returns -1.
>>
>>-- In Rtems_filesystem_evaluate_parent()
>>
>>msdos_eval_path() (with ".." as path) here we go through MSDOS_UP_DIR.
>>Returns an error (se below).
>>
>>
>>/DANIEL
>>
>>
>>
>>>-----Original Message-----
>>>From: Eugeny S. Mints [mailto:emints at ru.mvista.com] 
>>>Sent: Thursday, November 18, 2004 4:17 PM
>>>To: Daniel Gustafsson
>>>Cc: 'Thomas Doerfler'; rtems-users at rtems.com
>>>Subject: Re: Dosfs question..?
>>>
>>>Daniel Gustafsson wrote:
>>>
>>>> 
>>>>Hi.
>>>>
>>>>I have debugged the unlink() and the error occurs in 
>>>
>>>msdos_eval_path().
>>>
>>>>-- in msdos_eval_path(), line 114
>>>>...
>>>>switch(type)
>>>>{
>>>>case MSDOS_UP_DIR:
>>>>
>>>>if (fat_fd->fat_file_type != FAT_DIRECTORY)		-->
>>>>fat_fd->fat_file_type = 5 = RTEMS_FILESYSTEM_MEMORY_FILE = FAT_FILE
>>>>	errno = ENOTDIR;					
>>>
>>>	-->
>>>
>>>>ERROR!!!
>>>>...
>>>>--
>>>
>>>Well, the unlink(file) should not go through case 
>>>MSDOS_UP_DIR. Please, 
>>>try to
>>>debug why msdos_get_token() returns MSDOS_UP_DIR type for your file1.
>>>
>>>
>>>>Steps to mount and create file:
>>>>
>>>>1. msdos_format("/dev/ramdisk0", NULL);
>>>>2. ide_part_table_initialize("/dev/ramdisk0");
>>>>3. rtems_fs_mount(fs_table, sizeof(...), NULL);
>>>>
>>>>fs_table ~ { "/dev/ramdisk0", "/mnt/ramdisk0" , msdos_ops,
>>>>RTEMS_FILESYSTEM_READ_WRITE, flags, 0 }   --> example
>>>>
>>>>4. creat("/mnt/ramdisk0/file1", S_IREAD | S_IWRITE);
>>>>5. write to file 1
>>>>6. close file 1
>>>>7. unlink("/mnt/ramdisk0/file1");				
>>>
>>>	-->
>>>
>>>>Returns "NOT A DIRECTORY"
>>>>
>>>>
>>>>Everything is OK but the unlink.
>>>>
>>>>NOTIS: The /mnt/ramdisk0/ doesn't contain "." or "..". If I 
>>>
>>>make a sub
>>>
>>>>directory in /mnt/ramdisk0/ it will contain "." and "..". 
>>>>
>>>>
>>>>//DANIEL 
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Eugeny S. Mints [mailto:emints at ru.mvista.com] 
>>>>>Sent: Thursday, November 18, 2004 3:08 PM
>>>>>To: Thomas Doerfler
>>>>>Cc: Daniel Gustafsson; rtems-users at rtems.com
>>>>>Subject: Re: Dosfs question..?
>>>>>
>>>>>Hi All,
>>>>>
>>>>>Really strange return code. unlink() call should transform into 
>>>>>msdos_file_rmnod() routine call. Check whether the msdos routine is 
>>>>>reached if not - the issue somewhere in non-msdos related 
>>>
>>>code (start 
>>>
>>>>>from unlink() routine in libcsupport dir).
>>>>
>>>>
>>>>>How do you mount your msdos volume? I suppose you mount to some IMFS 
>>>>>directory (mnt?). My suggestion that the issue is somehow 
>>>
>>>connected to 
>>>
>>>>>the mount point.
>>>>>
>>>>>		Eugeny
>>>>>
>>>>>Thomas Doerfler wrote:
>>>>>
>>>>>
>>>>>>Daniel,
>>>>>>
>>>>>>I did a quick check of source codes, I really don't 
>>>>>>know what is going on in your system. 
>>>>>>
>>>>>>My idea, what you might do:
>>>>>>- Either step into the unlink call and find out 
>>>>>>where the error code is set.
>>>>>>
>>>>>>- Or: perform a grep over the libfs source code:
>>>>>>grep ENOTDIR cpukit/libfs/src/*/*.c
>>>>>>
>>>>>>You will get about 10 results. Set a breakpoint on 
>>>>>>every of these lines. Start your code. And look 
>>>>>>where the breakpoint is hit. 
>>>>>>
>>>>>>The rest is analysis then.
>>>>>>
>>>>>>By the way: which string do you pass to the unlink 
>>>>>>call?
>>>>>>
>>>>>>wkr,
>>>>>>Thomas.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hello.
>>>>>>>
>>>>>>>I am running rtems 4.6.2 on a ERC32 using TSIM as simulator 
>>>>>
>>>>>enviroment. Am
>>>>>
>>>>>
>>>>>>>using dosfs on the ramdisk. Everything works fine, as it 
>>>>>
>>>>>should, except the
>>>>>
>>>>>
>>>>>>>removal of files. I try to use the unlink() but it won't 
>>>>>
>>>>>accept the file
>>>>>
>>>>>
>>>>>>>(returns "NOT A DIRECTORY"???). What am I doing wrong. Is maybe the
>>>>>>>permissions is f**kt up (does dosfs support permissions 
>>>>>
>>>>>because I can't
>>>>>
>>>>>
>>>>>>>change them).
>>>>>>>
>>>>>>>Please help me someone or direct me to some documentation 
>>>>>
>>>>>about rtems dosfs.
>>>>>
>>>>>
>>>>>>>Many thanks to Thomas Doerfler for providing to the Rtems 
>>>>>
>>>>>community with a
>>>>>
>>>>>
>>>>>>>functional format function for dosfs.
>>>>>>>
>>>>>>>Regards
>>>>>>>Daniel Gustavsson 
>>>>>>
>>>>>>
>>>>>>--------------------------------------------
>>>>>>IMD Ingenieurbuero fuer Microcomputertechnik
>>>>>>Thomas Doerfler           Herbststrasse 8
>>>>>>D-82178 Puchheim          Germany
>>>>>>email:    Thomas.Doerfler at imd-systems.de
>>>>>>PGP public key available at: http://www.imd-
>>>>>>systems.de/pgp_keys.htm
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
> 
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_keys.htm
> 
> 
> 





More information about the users mailing list