[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TR : DOSFS unlink problem
- Date: Thu, 25 Nov 2004 20:06:31 +0100
- From: Thomas.Doerfler at imd-systems.de (Thomas Doerfler)
- Subject: TR : DOSFS unlink problem
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.
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.
> 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.
> -----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
> 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?
> > -----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-