Hi,
the linux code didn't reveal much to me, they seem to store the address
of the directory entry as the inode. This has the problem that renaming the
file (possibly moving the dirent address) invalidates the inode number.
Not good for us (we use the inode number for caching, for example).
The
On Sun, May 07, 2000 at 10:27:17PM +0200, Marcus Brinkmann wrote:
> Do you have any other tips for this situation, things to watch out for, or
> strategies how to get the location of the directory entry (seems I need a
> lookup at update time, because the address is not robust under rename
> oper
Date: Sun, 7 May 2000 22:27:17 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Hi,
as you may know, there are no inodes in the FATFS, all information being
stored directly in the directory entry.
Do I need some lock on the directory node when updating the node
information?
Hi,
as you may know, there are no inodes in the FATFS, all information being
stored directly in the directory entry.
Do I need some lock on the directory node when updating the node
information?
Do you have any other tips for this situation, things to watch out for, or
strategies how to get the
Hello,
I'm trying to compile Debian apt package. The first error was that MS_SYNC
is not defined. Looking at man pages for msync I found that MS_SYNC have to
be defined if _POSIX_SYNCHRONIZED_IO is defined which does. So my question
is why _POSIX_* is defined but MS_SYNC is not... Bug?
--
Og
Package: hurd
Version: N/A
Severity: normal
Hi,
again, I have no test case for this report, but only analysis of the code.
I am sure *if* it can occur, it is quite rare, so it's not urgent.
In ext2fs/pager.c (diskfs_grow), it seems that a file could shrink by one
block. Assume new_end_block > e
