TR : DOSFS unlink problem

[Thomas Doerfler]

Etienne,

I am really glad I was not the only one misinterpreting things 
:-)

Actually, the operation "rtems_filesystem_evaluate_parent" is 
performed on THE FILE, not on THE DIRECTORY, WHERE THE FILE IS 
LOCATED. The "evaluate_parent" more or less moves from the 
current location "THE_FILE" up one level with the ".." notation. 
In most OSs, this only works, when the current location is a 
directory, on RTEMS, it also works for files.

Try this:

1.) create a directory "/dir_a"
2.) create a file "/dira/file_a.txt" 
		with the contents "I am in file_a.txt"
3.) create a file "/dira/file_b.txt"
		with the contents "I am in file_b.txt"
4.) Now read /dira/file_a.txt, 
	you will get the text "I am in file_a.txt"
5.) Now read /dira/file_a.txt/../file_b.txt, 
	you will get the text "I am in file_b.txt"

You got the trick?

Unfortunately, this "trick" is not available in the current 
DOSFS implementation. Doing a ".." on a file is not supported.

wkr,
Thomas.




> Hi Thomas,
> Maybe sometimes I should look at the mailing list archive before jumping
> to asking yet another question :) RTFM as they say :)
> 
> Anyway, looking at unlink.c:unlink(), I find it strange to have to look
> at the parent directory of of the directory containing the file we want
> to unlink. Only the parent directory of the file should be looked at.
> This way, the call to rtems_filesystem_evaluate_parent() of the parent
> dir of the file to unlink seems unecessary. Looks like too much
> indirection. But I don't quite completely understand what is going on so
> I may be totally wrong. 
> 
> For now I just commented out the call to
> rtems_filesystem_evaluate_parent() (thank god RTEMS is open source!!!)
> until a solution is found.
> 
> Etienne
> 
> 
> 
> 
> -----Message d'origine-----
> De : Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de] 
> Envoyé : 25 novembre, 2004 13:39
> À : Etienne Fortin; Jennifer averett
> Cc : rtems-users at rtems.com
> Objet : Re: TR : DOSFS unlink problem
> 
> 
> Etienne,
> 
> as you mentioned in another message, somebody else already found 
> this problem. The reason is, that the unlink call want to check, 
> that the directory, where the file is located, is writable. 
> 
> Unfortunately, DOSFS does niot keep track of parents, so in the 
> structure maintained to manage a file, there is no pointer back 
> to the directory, where the file is located in. Therefore, a 
> basic operation to "move up one level in the directory tree" 
> fails in DOSFS and this makes unlink fail aswell.
> 
> I havve already investigated a bit about this problem :-)
> 
> I also have the feeling, that DOSFS currently does NOT implement 
> file attributes (is this right? sorry if I make wrong 
> assumptions here). Then it really does not make sense to walk 
> back to the parent directory of the file, and check the access 
> attributes (which are not meaningful at all).
> 
> I have filed a PR on this.
> 
> And I have no clue on how to solve this. Adding "go back to 
> parent" support seems a bit difficult. I have started in 
> maintaining a "parent_cln" field  in the fat_file_fd_t 
> structure, but this is only a start.
> 
> Any ideas? 
> 
> wkr,
> Thomas.
> 
> 
> > 
> > -----Message d'origine-----
> > De : Etienne Fortin [mailto:etienne.fortin at sensio.tv]
> > Envoyé : 25 novembre, 2004 13:02
> > À : rtems-users at rtems.com
> > Objet : DOSFS unlink problem
> > 
> > 
> > Hi everyone,
> > Me again, with my problems :)
> > 
> > I mounted a filesystem (DOSFS) on /storage.
> > 
> > In /storage I have a directory named bitstr.
> > 
> > So the basepath is /storage/bitstr.
> > 
> > I can create files in /storage/bitstr.
> > 
> > I can list the files with opendir/readdir...
> > 
> > BUT, I can't remove files in /storage/bitstr.
> > 
> > Somewhere in unlink, there's a call to 
> > rtems_filesystem_evaluate_parent(). It searchs for parent of 
> > /storage/bitstr (or so it seems). It finds the parent, and it's type 
> > is RTEMS_FILESYSTEM_MEMORY_FILE and not FAT_DIRECTORY. So, it throws 
> > up an error saying that it's not a directory.
> > 
> > Quite strange...
> > 
> > Any idea?
> > 
> > Etienne Fortin
> > Sensio
> > 
> 
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd- systems.de/pgp_keys.htm
> 
> 

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm