Re: unixfs: cache canonicalized unix paths corresponding to dos devices
Michael Jung <mjung(a)iss.tu-darmstadt.de> writes:
Changelog: Cache the canonicalized unix paths, which correspond to dos devices.
I don't think you want to do that. The goal of the new symlink scheme is to make it possible to change drive config on the fly, caching it would defeat that. -- Alexandre Julliard julliard(a)winehq.org
On Thursday 16 June 2005 17:02, Alexandre Julliard wrote:
I don't think you want to do that. The goal of the new symlink scheme is to make it possible to change drive config on the fly, caching it would defeat that.
You mean like while an application is running? Wouldn't that break a lot of applications, which store filenames in memory during runtime? In the current implementation, for every shitemid that is constructed, all drives are queried and their paths are canonicalized, which is a lot of disk i/o and string copying. Unixfs is really painfully slow. I guess we need some caching scheme, but if you don't like the current one, I'll give it some more thought. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de
From: "Michael Jung" <mjung(a)iss.tu-darmstadt.de>
In the current implementation, for every shitemid that is constructed, all drives are queried and their paths are canonicalized, which is a lot of disk i/o and string copying. Unixfs is really painfully slow. I guess we need some caching scheme, but if you don't like the current one, I'll give it some more thought.
Can't we just invalidate the cache if we notice things have changed? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
On Thursday 16 June 2005 23:11, Dimi Paun wrote:
Can't we just invalidate the cache if we notice things have changed?
Yes, that should'nt be too hard. Would that be ok, Alexandre? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de
Michael Jung <mjung(a)iss.tu-darmstadt.de> writes:
You mean like while an application is running? Wouldn't that break a lot of applications, which store filenames in memory during runtime?
No, you can remap drives on Windows too.
In the current implementation, for every shitemid that is constructed, all drives are queried and their paths are canonicalized, which is a lot of disk i/o and string copying. Unixfs is really painfully slow. I guess we need some caching scheme, but if you don't like the current one, I'll give it some more thought.
I think the whole canonicalization thing is suspect; you should never compare Unix path strings. If you have to compare paths you should use stat and compare device/inode. -- Alexandre Julliard julliard(a)winehq.org
On Thu, Jun 16, 2005 at 11:26:45PM +0200, Alexandre Julliard wrote:
I think the whole canonicalization thing is suspect; you should never compare Unix path strings. If you have to compare paths you should use stat and compare device/inode.
Except that some FS have difficulty generating unique inode numbers. (There is no answer to the problem though) David -- David Laight: david(a)l8s.co.uk
participants (4)
-
Alexandre Julliard -
David Laight -
Dimi Paun -
Michael Jung