[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] hostfs bug with unlink() when an open handle exists
On 14/12/2013 10:37, Helmut Karlowski wrote:
Run with fatfs.c (works):
pid 11 (gcc):
do_open(/f/usr/m68k-atari-mint/gcc-bin/4.6.3/../../../libexec/gcc/m68k-atari-mint/4.6.3/cc1):
Strange, I have no trouble when running MiKRO's gcc on ARAnyM on hostfs. I
mean to compile an Hello World.
Where does that /f/usr/m68k-atari-mint/gcc-bin/4.6.3 directory comes from? I
don't have any directory named gcc-bin.
Normally, that ../.. mess should be relative to the path of the gcc
executable. Try adding -v to gcc to see the paths when you compile.
Run with ../fatfs.c (works not):
pid 7 (gcc):
Fstat64(/v/home/hk/mymint/sys/.compile_ara/../../../libexec/gcc/m68k-atari-mint/4.6.3/cc1):
path2cookie returned -33
Here, the first part is totally bogus.
I suspect there is a problem in both cases (invalid root), but in the first
one it works by chance.
Also some paths look truncated, is there a limit in hostfs?
I don't know if there is a path name limit, but as I reported there are
several killer bugs in the hostfs :
- bogus symlink creation
- missing lock support
- here document bug
I'm pretty sure you hit the symlink bug-or-feature.
Please check your symlinks on the host side.
With hostfs, when you do "ln -s source destination", the source directory is
hacked before writing the symlink, while it should be left untouched. Then
the symlink is non-functionnal.
Long ago I complained to ARAnyM people, but I was told it was a feature.
A solution is to create the symlinks on the host, then use them inside MiNT.
Really, those hostfs bug-or-features makes it unusable for any serious work.
--
Vincent Rivière