Mikulas Patocka <[EMAIL PROTECTED]> wrote:
> On Sat, 30 Dec 2006, Paul Eggert wrote:
>> Mikulas Patocka <[EMAIL PROTECTED]> writes:
>>
>>> BTW. could it be possible to change POSIX on this issue?
>>
>> I very much doubt it. POSIX deliberately does not specify the
>> behavior of non-POSIX file syst
On Sat, 30 Dec 2006, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
BTW. could it be possible to change POSIX on this issue?
I very much doubt it. POSIX deliberately does not specify the
behavior of non-POSIX file systems, or of programs operating on
non-POSIX file systems
Mikulas Patocka <[EMAIL PROTECTED]> writes:
> BTW. could it be possible to change POSIX on this issue?
I very much doubt it. POSIX deliberately does not specify the
behavior of non-POSIX file systems, or of programs operating on
non-POSIX file systems. That's out of scope, just as it'd be out o
On Sat, 30 Dec 2006, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
...
There are a lot of packages that will break (sometimes subtly) on file
systems that lack stable file serial numbers: coreutils, diffutils,
git, tar, the list goes on for quite a ways. I'm afraid the only
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
...
>> There are a lot of packages that will break (sometimes subtly) on file
>> systems that lack stable file serial numbers: coreutils, diffutils,
>> git, tar, the list goes on for quite a ways. I'm afraid the only
>> current answer to this problem is "
Mikulas Patocka <[EMAIL PROTECTED]> writes:
> On Fri, 29 Dec 2006, Paul Eggert wrote:
>
>> Obviously stable file
>> serial numbers are implementable. They just aren't easily
>> implementable if one chooses the wrong implementation strategy.
>
> How would you implement them for FAT filesystem?
I
On Fri, 29 Dec 2006, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
If POSIX specifies something that is unimplementable (unique stable
inode numbers) the question is why to rely on it?
But it's easily implementable, if your file
Mikulas Patocka <[EMAIL PROTECTED]> writes:
>> Mikulas Patocka <[EMAIL PROTECTED]> writes:
>>
>>> If POSIX specifies something that is unimplementable (unique stable
>>> inode numbers) the question is why to rely on it?
>>
>> But it's easily implementable, if your file system was written with
>> P
Mikulas Patocka <[EMAIL PROTECTED]> writes:
If POSIX specifies something that is unimplementable (unique stable
inode numbers) the question is why to rely on it?
But it's easily implementable, if your file system was written with
POSIX in mind.
And if someone else designed it --- like FAT or
Mikulas Patocka <[EMAIL PROTECTED]> writes:
> If POSIX specifies something that is unimplementable (unique stable
> inode numbers) the question is why to rely on it?
But it's easily implementable, if your file system was written with
POSIX in mind.
In many cases the POSIX folks had to decide whe
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
Thank you for bringing this up. However, note that such systems are not
POSIX-compliant, since (as you must
Mikulas Patocka <[EMAIL PROTECTED]> writes:
They have 32-bit ino_t but 64-bit stat64.st_ino
(stat64 has unsigned long long st_ino) --- although kernel has the
deficiency that it can pass only 32-bit values to it --- BTW. can you
accept that fact that sizeof(st_ino) > sizeof(ino_t) in coreutils?
Mikulas Patocka <[EMAIL PROTECTED]> writes:
> They have 32-bit ino_t but 64-bit stat64.st_ino
> (stat64 has unsigned long long st_ino) --- although kernel has the
> deficiency that it can pass only 32-bit values to it --- BTW. can you
> accept that fact that sizeof(st_ino) > sizeof(ino_t) in coreu
Mikulas Patocka <[EMAIL PROTECTED]> writes:
> They have 32-bit ino_t but 64-bit stat64.st_ino
> (stat64 has unsigned long long st_ino) --- although kernel has the
> deficiency that it can pass only 32-bit values to it --- BTW. can you
> accept that fact that sizeof(st_ino) > sizeof(ino_t) in coreu
On Wed, 20 Dec 2006, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
Thank you for bringing this up. However, note that such systems
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
> BTW. looking at the code leads me to another observation --- all those
> security checks against 'rm'-vs-'mv' race break apart if the attacker is
Thank you for bringing this up. However, note that such systems are not
POSIX-compliant, since (as you mus
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
able to create directories with colliding inode number (which can happen
on 64-bit filesystems that can store more than 2^32 files --- for example
NFS
17 matches
Mail list logo
