Dosfs question..?

Daniel Gustafsson daniel.gustafsson at space.se
Fri Nov 19 08:40:21 UTC 2004


After the exchange of the if-statements I get the error "No such file or
directory instead" if I try to remove a file that are in a directory without
"." or "..".

If I create a directory with "." and ".." and if I unlink a file in this
directory a new error occurs. It is in msdos_find_name_in_fat_file().

It runs assert(ret == bts2rd) where ret = 123 (the filesize) and bts2rd =
512. "Program hangs"


First thought: It tries to read the file as a directory.



NOTE1: The same error uccurs regardles the path (if we are in root or
someware else).

NOTE2: Can someone please provide a link to sparc-rtems-gdb binary. It's not
in /pub/ and I'm am having trouble to build it myself. 

Now the file look like this.
msdos_eval.c:

..
while ((type != MSDOS_NO_MORE_PATH) && (type != MSDOS_INVALID_TOKEN)) 
  {
  type = msdos_get_token(&pathname[i], token, &len);
  i += len;
  
  fat_fd = pathloc->node_access; 
  
  switch (type) 
        {
         case MSDOS_UP_DIR:
            
    /*
    *  Am I at the root of this mounted filesystem?
    */
      
	if (pathloc->node_access == 
     		pathloc->mt_entry->mt_fs_root.node_access) 
             {
             /*
              *  Am I at the root of all filesystems?
           *  XXX: MSDOS is not supposed to be base fs.
           */
     if (pathloc->node_access == 
         rtems_filesystem_root.node_access) 
        {    
           break;       /* Throw out the .. in this case */
        }     
          else 
        {
           newloc = pathloc->mt_entry->mt_point_node;
           *pathloc = newloc;

           rc = fat_file_close(pathloc->mt_entry, fat_fd);
           if (rc != RC_OK)
           goto err;
                            
           rtems_semaphore_release(fs_info->vol_sema);
         return (*pathloc->ops->evalpath_h)(&(pathname[i-len]),
                                          flags, pathloc);
        }
        } 
           else 
        {
          rc = msdos_find_name(pathloc, token);
          if (rc != RC_OK)
           {
              if (rc == MSDOS_NAME_NOT_FOUND_ERR)
               {
                   errno = ENOENT;
                   rc = -1;
               }    
              goto error; 
            }  
 	}
            
            
       /*
       *  Only a directory can be decended into.
       */
         if (fat_fd->fat_file_type != FAT_DIRECTORY)
         {
           errno = ENOTDIR;
           rc = -1;
           goto error;
         }  
  
       break;

            case MSDOS_NAME:
                /*
                 *  Only a directory can be decended into.
                 */
                if (fat_fd->fat_file_type != FAT_DIRECTORY)
                {
                    errno = ENOTDIR;
                    rc = -1;
                    goto error;
                }  

                /*
                 *  Otherwise find the token name in the present location
and 
                 * set the node access to the point we have found.
                 */
                rc = msdos_find_name(pathloc, token);
                if (rc != RC_OK)
                {
                    if (rc == MSDOS_NAME_NOT_FOUND_ERR)
                    {
                        errno = ENOENT;
                        rc = -1;
                    }    
                    goto error; 
                }  
                break;

            case MSDOS_NO_MORE_PATH:
            case MSDOS_CURRENT_DIR:       
                break;

            case MSDOS_INVALID_TOKEN:
                errno = ENAMETOOLONG;
                rc = -1;
                goto error;
                break;
 
        }
    }
 

>-----Original Message-----
>From: Eugeny S. Mints [mailto:emints at ru.mvista.com] 
>Sent: Thursday, November 18, 2004 7:02 PM
>To: Thomas Doerfler
>Cc: Daniel Gustafsson; jennifer at oarcorp.com; rtems-users at rtems.com
>Subject: Re: Dosfs question..?
>
>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