Messages in this thread | | | Date | Thu, 13 Dec 2001 12:23:46 +0300 | From | Hans Reiser <> | Subject | Re: reiser4 (was Re: [PATCH] Revised extended attributes interface) |
| |
Andrew Pimlott wrote:
>On Wed, Dec 12, 2001 at 12:21:49AM +0300, Hans Reiser wrote: > >>Naming conventions are easy. >> > >Hans, > >While I look forward to your work, I think Anton points out some >issues that you really should try to address now, only you have not >understood them. Can I take a crack at posing some concrete >questions that manifest the issues? > >Let's imagine that we have a Linux system with an NTFS filesystem >and a reiserfs4 filesystem. You can make any tentative assumptions >about reiserfs4 and new API's that you like, I just want to have an >idea of how you envision the following working: > >First, I write a desktop application that wants to save an HTML file >along with some other object that contains the name of the creating >application. The latter can go anywhere you want, except in the >same stream as the HTML file. The user has requested that the >filename be /home/user/foo.html , and expects to be able to FTP this >file to his ISP with a standard FTP program. What calls does my >application make to store the HTML and the application name? If the >answer is different depending on whether /home/user is NTFS or >reiserfs4, explain both ways. > Are you sure that standard ftp will be able to handle extended attributes without modification?
One approach is to create a plugin called ..archive that when read is a virtual file consisting of an archive of everything in the directory. It would be interesting I think to attach said plugin to standard directories by default along with several other standard plugins like ..cat, etc.
> > >Second, I booted NT and created a directory in the NTFS filesystem >called /foo . In the directory, I created a file called bar. I >also created a named stream called bar, and an extended attribute >called bar. Now I boot Linux. What calls do I make to see each of >the three objects called bar? >
You access /foo/bar, /foo/bar/,,bar, /foo/..bar by name.
> > >The heart of Anton's argument is that the UNIX filesystem name space >is basically used up--there's just not much room to add new >semantics. The only obvious avenue for extension is, if /foo is not >a directory, you can give some interpretation to /foo/bar . But >this doesn't help if /foo is a directory. So something has to give, >and we want to see what will give in reiserfs4. > >Andrew > > Naming conventions are easy, but teaching user space is hard no matter whose scheme is used.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |