On Thu, May 10, 2007 at 12:44:19PM -0700, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> >E.g.
> >
> >long foofs_pathconf {
> > [_PC_LINK_MAX] = 16384,
> > [_PC_2_SYMLINKS]= 1,
>
> In general I agree. But what do you do for network filesystems? Maybe
> we'll have a
On Thu, May 10, 2007 at 12:44:19PM -0700, Ulrich Drepper wrote:
Christoph Hellwig wrote:
E.g.
long foofs_pathconf {
[_PC_LINK_MAX] = 16384,
[_PC_2_SYMLINKS]= 1,
In general I agree. But what do you do for network filesystems? Maybe
we'll have a network
On Thursday May 10, [EMAIL PROTECTED] wrote:
> Ulrich Drepper wrote:
> > Neil Brown wrote:
> >> Does it also specify how to find out what granularity is used by the
> >> filesystem? I had a need for this just recently and couldn't see any
> >> way to extract it.
> >
> > That's still on the
Christoph Hellwig wrote:
>
> I'd be happy to have them. While it's not the nicest API in the world
> it's in Posix and we have to support it at the library level, so we
> should better get it right.
>
> I'd like to avoid having a big swithc statement in every filesystem,
> though, instead of we
Christoph Hellwig wrote:
E.g.
long foofs_pathconf {
[_PC_LINK_MAX] = 16384,
[_PC_2_SYMLINKS]= 1,
In general I agree. But what do you do for network filesystems? Maybe
we'll have a network filesystem protocol which allows to query the
remote server about
On Thu, May 10, 2007 at 11:26:36AM -0700, Ulrich Drepper wrote:
> >That's still on the table. We might end up with an fpathconf() solution.
>
> OK, the pathconf()-based solution will most probably be in the next
> POSIX spec.
>
> Now, somebody has to provide a way to get to this information.
Ulrich Drepper wrote:
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
OK, the
Ulrich Drepper wrote:
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
OK, the
On Thu, May 10, 2007 at 11:26:36AM -0700, Ulrich Drepper wrote:
That's still on the table. We might end up with an fpathconf() solution.
OK, the pathconf()-based solution will most probably be in the next
POSIX spec.
Now, somebody has to provide a way to get to this information. The
Christoph Hellwig wrote:
E.g.
long foofs_pathconf {
[_PC_LINK_MAX] = 16384,
[_PC_2_SYMLINKS]= 1,
In general I agree. But what do you do for network filesystems? Maybe
we'll have a network filesystem protocol which allows to query the
remote server about
Christoph Hellwig wrote:
I'd be happy to have them. While it's not the nicest API in the world
it's in Posix and we have to support it at the library level, so we
should better get it right.
I'd like to avoid having a big swithc statement in every filesystem,
though, instead of we should
On Thursday May 10, [EMAIL PROTECTED] wrote:
Ulrich Drepper wrote:
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end
On Fri, 27 Apr 2007, H. Peter Anvin wrote:
The main use of atime seems to be to figure out when something can be
automatically deleted. Anyone else have other usage scenarios?
as a varient of this, I use it to help determine what files are actually needed
when building a chroot sandbox.
Ulrich Drepper wrote:
> H. Peter Anvin wrote:
>> The main use of atime seems to be to figure out when something can be
>> automatically deleted. Anyone else have other usage scenarios?
>
> It's not atime which cannot be set, it's ctime.
You're right, my brainfart.
-hpa
-
To unsubscribe
H. Peter Anvin wrote:
> The main use of atime seems to be to figure out when something can be
> automatically deleted. Anyone else have other usage scenarios?
It's not atime which cannot be set, it's ctime.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Ulrich Drepper wrote:
> H. Peter Anvin wrote:
>> Primarily to let a backup program restore the full state of the filesystem.
>
> Is this wanted? Or needed? I would think there are good reasons why
> this hasn't been done so far. Intrusion detection is one reason I can
> think of.
Well,
On Thursday April 26, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > Does it also specify how to find out what granularity is used by the
> > filesystem? I had a need for this just recently and couldn't see any
> > way to extract it.
>
> That's still on the table. We might end up with an
On Thursday April 26, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf()
Ulrich Drepper wrote:
H. Peter Anvin wrote:
Primarily to let a backup program restore the full state of the filesystem.
Is this wanted? Or needed? I would think there are good reasons why
this hasn't been done so far. Intrusion detection is one reason I can
think of.
Well, dump/restore
H. Peter Anvin wrote:
The main use of atime seems to be to figure out when something can be
automatically deleted. Anyone else have other usage scenarios?
It's not atime which cannot be set, it's ctime.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Ulrich Drepper wrote:
H. Peter Anvin wrote:
The main use of atime seems to be to figure out when something can be
automatically deleted. Anyone else have other usage scenarios?
It's not atime which cannot be set, it's ctime.
You're right, my brainfart.
-hpa
-
To unsubscribe from
On Fri, 27 Apr 2007, H. Peter Anvin wrote:
The main use of atime seems to be to figure out when something can be
automatically deleted. Anyone else have other usage scenarios?
as a varient of this, I use it to help determine what files are actually needed
when building a chroot sandbox.
Neil Brown wrote:
> Does it also specify how to find out what granularity is used by the
> filesystem? I had a need for this just recently and couldn't see any
> way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧
On Thursday April 26, [EMAIL PROTECTED] wrote:
> The next revision of POSIX will support fine-grained filesystem
> timestamps the way we already support. struct stat will report
> nanosecond values. So far so good.
Does it also specify how to find out what granularity is used by the
H. Peter Anvin wrote:
> Primarily to let a backup program restore the full state of the filesystem.
Is this wanted? Or needed? I would think there are good reasons why
this hasn't been done so far. Intrusion detection is one reason I can
think of.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
Ulrich Drepper wrote:
> H. Peter Anvin wrote:
>> I'm a bit leery of abusing the timespec value like this, though. A
>> flags field seem like it would be cleaner.
>
> It's ugly. Then you have the parameter, which might have nice valid
> values, and they get ignored. I thought about it when this
H. Peter Anvin wrote:
> I'm a bit leery of abusing the timespec value like this, though. A
> flags field seem like it would be cleaner.
It's ugly. Then you have the parameter, which might have nice valid
values, and they get ignored. I thought about it when this was
discussed in the working
Andrew Morton wrote:
> Does the spec say what the OS should do if (ts_nsec => 1e9)?
Yes, return EINVAL. We already do this. It's just that now we have to
recognize two special values.
> OK, so there's no collision on ts_nsec if unnormalised timespecs are
> disallowed.
Indeed, that's the
Andrew Morton wrote:
> On Thu, 26 Apr 2007 18:49:05 -0400 Ulrich Drepper <[EMAIL PROTECTED]> wrote:
>>
>> If the tv_nsec value of either of the elements of the utimes parameter to
>> utimensat() is UTIME_OMIT no update of that respective value is performed.
>
> ITYM "If the value of either of
On Thu, 26 Apr 2007 18:49:05 -0400 Ulrich Drepper <[EMAIL PROTECTED]> wrote:
>
> The next revision of POSIX will support fine-grained filesystem timestamps
> the way we already support. struct stat will report nanosecond values. So
> far so good.
>
> During the development one additional
The next revision of POSIX will support fine-grained filesystem timestamps the
way we already support. struct stat will report nanosecond values. So far so
good.
During the development one additional problem was found: there is no interface
to set the file timestamp with that precision.
The next revision of POSIX will support fine-grained filesystem timestamps the
way we already support. struct stat will report nanosecond values. So far so
good.
During the development one additional problem was found: there is no interface
to set the file timestamp with that precision.
On Thu, 26 Apr 2007 18:49:05 -0400 Ulrich Drepper [EMAIL PROTECTED] wrote:
The next revision of POSIX will support fine-grained filesystem timestamps
the way we already support. struct stat will report nanosecond values. So
far so good.
During the development one additional problem
Andrew Morton wrote:
On Thu, 26 Apr 2007 18:49:05 -0400 Ulrich Drepper [EMAIL PROTECTED] wrote:
If the tv_nsec value of either of the elements of the utimes parameter to
utimensat() is UTIME_OMIT no update of that respective value is performed.
ITYM If the value of either of the
Andrew Morton wrote:
Does the spec say what the OS should do if (ts_nsec = 1e9)?
Yes, return EINVAL. We already do this. It's just that now we have to
recognize two special values.
OK, so there's no collision on ts_nsec if unnormalised timespecs are
disallowed.
Indeed, that's the basis of
H. Peter Anvin wrote:
I'm a bit leery of abusing the timespec value like this, though. A
flags field seem like it would be cleaner.
It's ugly. Then you have the parameter, which might have nice valid
values, and they get ignored. I thought about it when this was
discussed in the working
Ulrich Drepper wrote:
H. Peter Anvin wrote:
I'm a bit leery of abusing the timespec value like this, though. A
flags field seem like it would be cleaner.
It's ugly. Then you have the parameter, which might have nice valid
values, and they get ignored. I thought about it when this was
H. Peter Anvin wrote:
Primarily to let a backup program restore the full state of the filesystem.
Is this wanted? Or needed? I would think there are good reasons why
this hasn't been done so far. Intrusion detection is one reason I can
think of.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
On Thursday April 26, [EMAIL PROTECTED] wrote:
The next revision of POSIX will support fine-grained filesystem
timestamps the way we already support. struct stat will report
nanosecond values. So far so good.
Does it also specify how to find out what granularity is used by the
filesystem?
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
40 matches
Mail list logo
