[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TR : DOSFS unlink problem
- Date: Fri, 26 Nov 2004 16:10:02 +0300
- From: emints at ru.mvista.com (Eugeny S. Mints)
- Subject: TR : DOSFS unlink problem
Sergei Organov wrote:
> "Thomas Doerfler" <Thomas.Doerfler at imd-systems.de> writes:
>>I am really glad I was not the only one misinterpreting things
> You are definitely not alone. Some time ago I had a need to attach my
> own very simple file system to the RTEMS, and it was a real headache. My
> filesystem doesn't have any support for directories, still the glue code
> needs to handle all that ./.././.././ stuff itself, and it was a lot of
> try-and-fix steps to get it work.
> I'm sorry to say it, but I've got impression that all this eval_path
> stuff is over-complicated and error-prone. Every file system implementing
> ./.. itself with its own bugs and misunderstandings sounds like a way to
> disaster. The only reason I kept silence is my ignorance of how it could
> be done more elegantly. Maybe to borrow some ideas from Linux VFS
> interfaces or from FreeBSD sources?
>>5.) Now read /dira/file_a.txt/../file_b.txt,
>> you will get the text "I am in file_b.txt"
> Cool! The only question is -- is it a bug or a feature? ;)
it IS definilty a BUG!
I remember there was a sort of discussion about unlink() at dosfs
development time but I do not remember what was the core of the issue -
need to search mail arch.
I aslo do believe I could not leave removing a file/dir from the root
dir functionality untested, thus I suggest it workED. Need time ti