starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 05:16:00 +03:00

[GH-ISSUE #2126] Test for object names exceeding NAME_MAX #1085

New issue

Closed

opened 2026-03-04 01:51:16 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 01:51:16 +03:00

Owner

Originally created by @ggtakec on GitHub (Mar 11, 2023).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2126

Additional Information

Version of s3fs being used (`s3fs --version`)

v1.91(current master branch)

Details about issue

Derived from this issue as pointed out by #2123.

Object names exceeding NAME_MAX should be tested to confirm behavior.
You should consider the consequences of that action and make corrections if necessary.

Originally created by @ggtakec on GitHub (Mar 11, 2023). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2126 ### Additional Information #### Version of s3fs being used (`s3fs --version`) v1.91(current master branch) ### Details about issue Derived from this issue as pointed out by #2123. Object names exceeding NAME_MAX should be tested to confirm behavior. You should consider the consequences of that action and make corrections if necessary.

kerem

2026-03-04 01:51:16 +03:00

closed this issue
added the
testing
label

kerem commented

2026-03-04 01:51:17 +03:00

Author

Owner

@ggtakec commented on GitHub (Mar 11, 2023):

I ran a very simple test.
I tested it by specifying a file name longer than NAME_MAX(=255 on my host) (260 here) in TEST_TEXT_FILE of test-utils.sh.
If set 260 file name length, the operation was stable without any particular errors.
I'll try it later with a longer file name.

@ggtakec commented on GitHub (Mar 11, 2023): I ran a very simple test. I tested it by specifying a file name longer than `NAME_MAX`(=255 on my host) (260 here) in `TEST_TEXT_FILE` of `test-utils.sh`. If set 260 file name length, the operation was stable without any particular errors. I'll try it later with a longer file name.

kerem commented

2026-03-04 01:51:17 +03:00

Author

Owner

@ggtakec commented on GitHub (Mar 11, 2023):

The test seems to pass even if I name the file over 4096(4100).
@gaul
If there's anything else I should test, please let me know.

@ggtakec commented on GitHub (Mar 11, 2023): The test seems to pass even if I name the file over 4096(4100). @gaul If there's anything else I should test, please let me know.

kerem commented

2026-03-04 01:51:17 +03:00

Author

Owner

@gaul commented on GitHub (May 30, 2023):

There are two behaviors we could test:

Try to create a file with a NAME_MAX + 1 length name, should fail with ENAMETOOLONG before s3fs sees it
Try to read an object created by AWS CLI that with a NAME_MAX + 1 length name. I don't know what s3fs does here but I don't believe that FUSE will allow open to open this or readdir to list it. My concern is that s3fs will truncate this to NAME_MAX when instead it should skip it and log a warning message.

@gaul commented on GitHub (May 30, 2023): There are two behaviors we could test: * Try to create a file with a `NAME_MAX` + 1 length name, should fail with `ENAMETOOLONG` before s3fs sees it * Try to read an object created by AWS CLI that with a `NAME_MAX + 1` length name. I don't know what s3fs does here but I don't believe that FUSE will allow `open` to open this or `readdir` to list it. My concern is that s3fs will truncate this to `NAME_MAX` when instead it should skip it and log a warning message.

kerem commented

2026-03-04 01:51:17 +03:00

Author

Owner

@ggtakec commented on GitHub (Jun 4, 2023):

@gaul I re-confirmed file names exceeding NAME_MAX(255).
As that result, it is different depending on whether the cache directory is used or not.

list(ls command)
File names exceeding NAME_MAX(255) can be displayed without problems.(no error)
read(cat command)
The results differ depending on whether or not the cache directory (use_cache option) is used.
If the cache is not used, reading the file succeeds.
When using a cache, an error occurs when creating a cache file(under the cache directory), ENAMETOOLONG is received, and an EIO error occurs.
write(touch command)
Without caching, writing the file succeeds.
An ENOENT error occurs when using the cache.(The ENOENT error that occurred during processing is returned.)

These seem to only occur when the s3fs process needs to operate on local disks with file names that exceed NAME_MAX.

@ggtakec commented on GitHub (Jun 4, 2023): @gaul I re-confirmed file names exceeding NAME_MAX(255). As that result, it is different depending on whether the cache directory is used or not. - list(`ls` command) File names exceeding NAME_MAX(255) can be displayed without problems.(no error) - read(`cat` command) The results differ depending on whether or not the cache directory (`use_cache` option) is used. If the cache is not used, reading the file succeeds. When using a cache, an error occurs when creating a cache file(under the cache directory), `ENAMETOOLONG` is received, and an `EIO` error occurs. - write(`touch` command) Without caching, writing the file succeeds. An `ENOENT` error occurs when using the cache.(The `ENOENT` error that occurred during processing is returned.) These seem to only occur when the s3fs process needs to operate on local disks with file names that exceed NAME_MAX.

kerem commented

2026-03-04 01:51:17 +03:00

Author

Owner

@gaul commented on GitHub (Sep 8, 2023):

Addressed by 9fb4c32c6a. There are some issues when using the cache but this is due to the underlying filesystem limitation.

@gaul commented on GitHub (Sep 8, 2023): Addressed by 9fb4c32c6a4ee5916e807c5ceb7c60175455c38c. There are some issues when using the cache but this is due to the underlying filesystem limitation.

kerem referenced this issue

2026-03-04 02:02:14 +03:00

[PR #1085] [MERGED] Remove recursive locking #1801