[En-Nut-Discussion] Question about the Peanut filesystem

[Jesper Hansen]

1. You're very very wrong. ;-)

2. I see a few problems with that. Apart from not being thread local :-O
it would take a long time to traverse the tree to get to the final file 
  (or directory) element. It does of course also eat some memory, 
especially if you have a number of different paths stored.
My version is probably rather FAT specific, yes. It may be possible to 
use the same approach on some other FS's directly, I have not looked at 
PNUT or the Flash filesystem enough to know how they work.
The advantage is that it is superlow on memory and is fast as there is 
no search involved to get to a certain directory.

Not sure if I understood your question right, but I think you ask if 
it's possible to "back up" the three to obtain the current dir from the 
cluster number. Well, the size of the directory doesn't matter, as the 
dircluster would always be the first in the cluster chain. The dot and 
dotdot entries can be used to back one step up and the previous dir 
could then be found within that dir with a scan. Then up a level again 
until there is no more dot enties (identifying the root). The path name 
would then be built up from the end up. Shouldn't be as bad as it sounds ;-)

I look forward to see more of the PHAT code. I have two Nut 3.0 on the 
way, so I have something to play with.

/Jesper

Harald Kipp wrote:
> Jesper,
> 
> Really advanced, though I don't think I'll make the cwd thread-local.
> At least not by default. Still two interesting aspects.
> 
> 1. I'm programming with threads since my old PASCAL days at the
> university and I'm always wondering about other people's request
> for local thread data. It's in the ROM part of my brain, that
> threads are not processes and thus do not have local data. Please
> keep reminding me from time to time that I'm wrong here.
> 
> 2. In the PHAT test version (not the published one) I implemented
> the current directory, but used the full path string, allocated from
> heap. This is generally useful for all file systems, but memory hungry.
> Your solution is FAT dependent, which doesn't provide a real problem
> because every driver can provide his specific function to implement
> a variant. My questions: Is it possible to query the full path of the
> current working directory without too much hassle? Any problems with
> large directories, spanning two or more clusters?
> 
> Harald
> 
> At 20:20 12.01.2006 +0100, you wrote:
> 
>> td_drive is a pointer to the NUTDEVICE struct for the current drive, 
>> and obviusly, td_dircluster to to current direcoty cluster on the drive.
> 
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 
>