Opened 6 years ago
Last modified 5 years ago
#14311 new bug
utimes(2) does not set the correct microsecond for modification time
Reported by: | leorize | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | File Systems/BFS | Version: | R1/Development |
Keywords: | Cc: | nielx | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Attached below is a program that creates a file and set its modification time to 1000
microsecond using utimes(2)
How to run:
$ gcc -o ut ut.c $ ./ut
Expected output:
Modified second: 0 Modified nanosec: 1000000
Got:
Modified second: 0 Modified nanosec: 786432
Attachments (1)
Change History (5)
by , 6 years ago
comment:1 by , 6 years ago
patch: | 0 → 1 |
---|
comment:2 by , 6 years ago
patch: | 1 → 0 |
---|
comment:3 by , 6 years ago
Component: | System/POSIX → File Systems/BFS |
---|---|
Owner: | changed from | to
comment:4 by , 5 years ago
Cc: | added |
---|
Note:
See TracTickets
for help on using tickets.
It seems to be on BFS? Because write_stat will use: https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/file_systems/bfs/bfs.h#L242 and https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/file_systems/bfs/bfs.h#L287 to calculate the on-disk mtime.
and read_stat: https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/file_systems/bfs/bfs.h#L248
786432 is 48 << 14, (((1000000 + 16383) >> 14) & 0xfff0) is exactly 48.
So it works as badly as designed :)