Dosfs question..?

[Thomas Doerfler]

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" ?

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