'Not a directory'

'Not a directory'

[Marcos Dione]

  I'm playing with a new fs developed by myself. I reached the stage
where I can mount the fs and even read the root's inode. but when I
try to cd into de mountpoint, chdir(2) complais that 'Not a directory'.

  doing a 'ls -l' I see that the mountpoint has the mode, dates and
size of the directory being mounted. the mode is 040755, so I don't
see the problem. also, using ramfs as reference, I note that the
directory is not inspected in any way, so I think that is not a
problem if I didn't developed the super, inode and file ops *yet*.

  also, I would *really* appreciate any link to any docs about
implementing filesystems for linux (e.g., what should all the *_ops
functions must do, return, etc., which should be reimplemented or
which could be ignored or even use the generic_* ones, and so on)

  best regards.

Re: 'Not a directory'

[Jan Hudec]

On Sun, May 26, 2002 at 11:18:40PM -0300, Marcos Dione wrote:
>   I'm playing with a new fs developed by myself. I reached the stage
> where I can mount the fs and even read the root's inode. but when I
> try to cd into de mountpoint, chdir(2) complais that 'Not a directory'.

... so go through the code path where it can return -ENOTDIR

>   doing a 'ls -l' I see that the mountpoint has the mode, dates and
> size of the directory being mounted. the mode is 040755, so I don't
> see the problem. also, using ramfs as reference, I note that the
> directory is not inspected in any way, so I think that is not a
> problem if I didn't developed the super, inode and file ops *yet*.

... what about this check in namei.c:607
                if (lookup_flags & LOOKUP_DIRECTORY) {
                        err = -ENOTDIR;
                        if (!inode->i_op || !inode->i_op->lookup)
                                break;
                }

>   also, I would *really* appreciate any link to any docs about
> implementing filesystems for linux (e.g., what should all the *_ops
> functions must do, return, etc., which should be reimplemented or
> which could be ignored or even use the generic_* ones, and so on)

There are Documentation/filesystems/vfs.txt and Locking files in kernel
source, that contain some documentation. And for the rest there is
tmpfs, where you can look what things must be done to keep vfs happy
(like when to put/get inode/dentry, how to map a page for write and so
on).

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

Re: 'Not a directory'

[Anton Altaparmakov]

At 03:18 27/05/02, Marcos Dione wrote:
>   also, I would *really* appreciate any link to any docs about
>implementing filesystems for linux (e.g., what should all the *_ops
>functions must do, return, etc., which should be reimplemented or
>which could be ignored or even use the generic_* ones, and so on)

http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/vfs.html
http://www.moses.uklinux.net/patches/lki.html

The first is a bit out of date but still very valuable.

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: 'Not a directory'

[Greg KH]

On Sun, May 26, 2002 at 11:18:40PM -0300, Marcos Dione wrote:
> 
>   I'm playing with a new fs developed by myself. I reached the stage
> where I can mount the fs and even read the root's inode. but when I
> try to cd into de mountpoint, chdir(2) complais that 'Not a directory'.
> 
>   doing a 'ls -l' I see that the mountpoint has the mode, dates and
> size of the directory being mounted. the mode is 040755, so I don't
> see the problem. also, using ramfs as reference, I note that the
> directory is not inspected in any way, so I think that is not a
> problem if I didn't developed the super, inode and file ops *yet*.
> 
>   also, I would *really* appreciate any link to any docs about
> implementing filesystems for linux (e.g., what should all the *_ops
> functions must do, return, etc., which should be reimplemented or
> which could be ignored or even use the generic_* ones, and so on)

For a ram based filesystem, there's an ok article in the May issue of
Linux Journal on some of the things you need to do for 2.4:
	http://www.linuxjournal.com/article.php?sid=5633

Also take a look at the code for pcihpfs in the 2.4 kernel at
drivers/hotplug/pci_hotplug_core.c and driverfs and usbfs in the 2.5
kernel for other examples of ram based filesystems that were based off
of ramfs (actually pcihpfs was based off of driverfs which was based off
of ramfs...)

Hope this helps,

greg k-h