[Bug 1001193] New: abnormal behavior readdir on fat16

[Bug 1001193] New: abnormal behavior readdir on fat16

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001193

           Summary: abnormal behavior readdir on fat16
           Product: eCos
           Version: unknown
          Platform: All
        OS/Version: Other
            Status: UNCONFIRMED
          Severity: minor
          Priority: low
         Component: FAT filesystem
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: arteminus@yandex.ru
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


I heve code:
...
  ret = mount("/dev/synthdisk0/" , "/", "fatfs");
  DIR *dirp;
  dirp = opendir( "/dir3/" );
  while (true) {
    struct dirent *entry = readdir( dirp );
    if( entry == NULL ) break;
    debug_printf("%s",entry->d_name);
  }
...
And have directory(filesystem fat16):
/mnt/loop/dir3# ls
dir1  dir2  file1  file2  mmm  text

Why I get list1 instead list2?
list1:
.
..
Af
FILE1
Af
FILE2
Ad
DIR1
Ad
DIR2
At
TEXT
Am
MMM

list2:
.
..
FILE1
FILE2
DIR1
DIR2
TEXT
MMM

I think this is a mistake(may be at work with long file names) and should
correct in
/packages/fs/fat/current/src/fatfs_supp.c in function
static int
read_next_raw_dentry(fatfs_disk_t        *disk,
                     fatfs_data_pos_t    *pos,
                     fat_raw_dir_entry_t *dentry)
{
...
+++if(dentry->attr == 16 /*dir*/ && dentry->attr == 32 /*file*/)
...
}

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001193] abnormal behavior readdir on fat16

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001193

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjones@linear.com

--- Comment #1 from Mike Jones <mjones@linear.com> ---
I am seeing this same behavior. In the process of debugging, I noticed the
FAT16/FAT32 discovery during mount uses number of clusters and not an
attribute. This means that if I format the SD on Linux, it believes it is
FAT16, and if I format the SD on DOS, it thinks it is FAT32. Neither change the
results that give me the extra directories.

The detected attribute of the directory is 0xF. That means a hidden read only
system file. No such files show up when the SD is mounted on DOS or Linux. The
cluster is 0 and file size -1.

I believe this means it is the directory '..'

Not being an expert about FAT, it seems unusual to find more than one of these
in the root dir. Perhaps it has something to do with how the table is searched
where it goes into a dir, finds this, and goes back up. If so, perhaps the code
should filter out the '..'.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001193] abnormal behavior readdir on fat16

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001193

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjones@linear.com

--- Comment #1 from Mike Jones <mjones@linear.com> ---
I am seeing this same behavior. In the process of debugging, I noticed the
FAT16/FAT32 discovery during mount uses number of clusters and not an
attribute. This means that if I format the SD on Linux, it believes it is
FAT16, and if I format the SD on DOS, it thinks it is FAT32. Neither change the
results that give me the extra directories.

The detected attribute of the directory is 0xF. That means a hidden read only
system file. No such files show up when the SD is mounted on DOS or Linux. The
cluster is 0 and file size -1.

I believe this means it is the directory '..'

Not being an expert about FAT, it seems unusual to find more than one of these
in the root dir. Perhaps it has something to do with how the table is searched
where it goes into a dir, finds this, and goes back up. If so, perhaps the code
should filter out the '..'.

-- 
You are receiving this mail because:
You are the assignee for the bug.