[GH-ISSUE #1202] Create time of directory is reported as zero #637

Closed
opened 2026-03-04 01:47:26 +03:00 by kerem · 9 comments
Owner

Originally created by @bkamau on GitHub (Nov 20, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1202

Version of s3fs being used (s3fs --version)

s3fs_fuse 1.85

GNU/Linux Distribution, if applicable (cat /etc/os-release)

alpine 3.9

s3fs command line used, if applicable

s3fs "$BUCKET" "$MOUNT_PATH" \
    -o ro \
    -o noatime \
    -o passwd_file="$S3CRED,use_path_request_style,url=$MINIO_ENDPOINT"

Details about issue

Directories inside the mounted bucket has time set to 0 like this
drwxr-x--- 1 1000 1000 0 Jan 1 1970 PUBLIC

Files inside the PUBLIC directory has proper time set though
Close related to https://github.com/s3fs-fuse/s3fs-fuse/issues/771

Originally created by @bkamau on GitHub (Nov 20, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1202 #### Version of s3fs being used (s3fs --version) s3fs_fuse 1.85 #### GNU/Linux Distribution, if applicable (cat /etc/os-release) alpine 3.9 #### s3fs command line used, if applicable ``` s3fs "$BUCKET" "$MOUNT_PATH" \ -o ro \ -o noatime \ -o passwd_file="$S3CRED,use_path_request_style,url=$MINIO_ENDPOINT" ``` ### Details about issue Directories inside the mounted bucket has time set to 0 like this drwxr-x--- 1 1000 1000 0 Jan 1 1970 PUBLIC Files inside the PUBLIC directory has proper time set though Close related to https://github.com/s3fs-fuse/s3fs-fuse/issues/771
kerem 2026-03-04 01:47:26 +03:00
  • closed this issue
  • added the
    need info
    label
Author
Owner

@gaul commented on GitHub (Feb 2, 2020):

Are these times zero for objects created from s3fs or from an external tool?

<!-- gh-comment-id:581119660 --> @gaul commented on GitHub (Feb 2, 2020): Are these times zero for objects created from s3fs or from an external tool?
Author
Owner

@bkamau commented on GitHub (Feb 12, 2020):

They are created by external tool. Please note that this applies to directories, not the objects inside that given directory.

<!-- gh-comment-id:585257351 --> @bkamau commented on GitHub (Feb 12, 2020): They are created by external tool. Please note that this applies to directories, not the objects inside that given directory.
Author
Owner

@Wang-Kai commented on GitHub (Feb 18, 2020):

They are created by external tool. Please note that this applies to directories, not the objects inside that given directory.

Have you solve it ? i met the same issue .

<!-- gh-comment-id:587279259 --> @Wang-Kai commented on GitHub (Feb 18, 2020): > They are created by external tool. Please note that this applies to directories, not the objects inside that given directory. Have you solve it ? i met the same issue .
Author
Owner

@Wang-Kai commented on GitHub (Feb 18, 2020):

I met the same issue, after executed s3fs mydirectory ...,the inode of mydirectory changed, and the create time is zero .

# stat mydirectory
  File: mydirectory
  Size: 0         	Blocks: 1          IO Block: 4096   directory
Device: 8eh/142d	Inode: 1           Links: 1
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1970-01-01 00:00:00.000000000 +0000
Modify: 1970-01-01 00:00:00.000000000 +0000
Change: 1970-01-01 00:00:00.000000000 +0000
 Birth: -

And, after execute umount s3fs, the date of directory is correct .

<!-- gh-comment-id:587291932 --> @Wang-Kai commented on GitHub (Feb 18, 2020): I met the same issue, after executed `s3fs mydirectory ...`,the inode of `mydirectory` changed, and the create time is zero . ``` # stat mydirectory File: mydirectory Size: 0 Blocks: 1 IO Block: 4096 directory Device: 8eh/142d Inode: 1 Links: 1 Access: (0700/drwx------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 1970-01-01 00:00:00.000000000 +0000 Modify: 1970-01-01 00:00:00.000000000 +0000 Change: 1970-01-01 00:00:00.000000000 +0000 Birth: - ``` And, after execute `umount s3fs`, the date of directory is correct .
Author
Owner

@gaul commented on GitHub (Oct 10, 2020):

Could you test with the latest master? It includes 059cc57ba6.

<!-- gh-comment-id:706513235 --> @gaul commented on GitHub (Oct 10, 2020): Could you test with the latest master? It includes 059cc57ba6914229dbd7238b902ba76d87643c6e.
Author
Owner

@gaul commented on GitHub (Nov 15, 2020):

Please reopen if symptoms persist.

<!-- gh-comment-id:727561766 --> @gaul commented on GitHub (Nov 15, 2020): Please reopen if symptoms persist.
Author
Owner

@bkamau commented on GitHub (Jun 2, 2022):

@gaul Please re-open the issue as the problem is still visible with v1.91.

<!-- gh-comment-id:1144584773 --> @bkamau commented on GitHub (Jun 2, 2022): @gaul Please re-open the issue as the problem is still visible with **v1.91**.
Author
Owner

@gaul commented on GitHub (Jun 12, 2022):

I misunderstood the symptom -- if you run:

s3fs bucket mnt/
echo data | aws_cli s3 cp - "s3://bucket/directory/file"
ls -ld mnt/directory

You will see the default permissions 750 and a default 0 atime/ctime/mtime. This is intentional -- directory does not exist and s3fs must provide some value so it defaults to 0. What do you expect to happen?

<!-- gh-comment-id:1153148502 --> @gaul commented on GitHub (Jun 12, 2022): I misunderstood the symptom -- if you run: ``` s3fs bucket mnt/ echo data | aws_cli s3 cp - "s3://bucket/directory/file" ls -ld mnt/directory ``` You will see the default permissions 750 and a default 0 atime/ctime/mtime. This is intentional -- `directory` does not exist and s3fs must provide some value so it defaults to 0. What do you expect to happen?
Author
Owner

@bronger commented on GitHub (Jul 11, 2022):

Does an S3 store save a timestamp for directories at all?

<!-- gh-comment-id:1179850383 --> @bronger commented on GitHub (Jul 11, 2022): Does an S3 store save a timestamp for directories at all?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#637
No description provided.