"testing/" directory remains after formatting volume with shards

[Light-City]

What happened:

When formatting a new volume with --shards > 0 (e.g., --shards=10 --bucket=s3://mybucket/data-%d), the test directory testing/ is not cleaned up from the object storage.

The root cause is that sharded.pick(key) hashes the entire key string. During the format test:
A test object is created with a key like testing/abcdefg. It is hashed and routed to Shard A.
After the test, the command attempts to delete the prefix testing/. However, the string testing/ hashes to a different value, routing the request to Shard B.

What you expected to happen:

should delete testing dir.

How to reproduce it (as minimally and precisely as possible):

cmd is:

./juicefs format redis://127.0.0.1:6379 myjfs --shards=120 --bucket=metadata/juicefs-%d

Anything else we need to know?

Environment:

• JuiceFS version (use juicefs --version) or Hadoop Java SDK version: 1.4.0-dev+2026-01-01.f1701da0

[jiefenghuang]

The current issue uses sharding, and the backend storage is a filesystem type (this problem doesn’t occur with S3 type). It leaves behind an empty directory (possibly with multiple levels).
When deleting a prefix, we need to traverse all filesystem-type backend stores to delete the prefix directory. The fix in #6577 does not completely solve the problem.

I think we can keep the current state for now since it doesn’t have a major impact. Later we will consider whether it’s necessary to clean up the empty directories.

[Light-City]

The current issue uses sharding, and the backend storage is a filesystem type (this problem doesn’t occur with S3 type). It leaves behind an empty directory (possibly with multiple levels). When deleting a prefix, we need to traverse all filesystem-type backend stores to delete the prefix directory. The fix in #6577 does not completely solve the problem.

I think we can keep the current state for now since it doesn’t have a major impact. Later we will consider whether it’s necessary to clean up the empty directories.

“When deleting a prefix, we need to traverse all filesystem-type backend stores to delete the prefix directory.” Does this sentence mean that all buckets need to be deleted?
For example, if the "testing" subdirectory exists in bucket1, bucket2, etc., does it mean that the "testing" subdirectory in all buckets should be deleted?

From my personal understanding, the current problem involves files being generated in the bucket, so only the empty "testing" directory in the bucket corresponding to the current file needs to be deleted, not all of them, right?

[jiefenghuang]

Yes, as of now the format test function just needs to be handled according to PR 6577. However, deleting this empty directory for that change feels a bit heavy, so for now i think let's not to modify it since it doesn’t have much impact.

[Light-City]

Yes, as of now the format test function just needs to be handled according to PR 6577. However, deleting this empty directory for that change feels a bit heavy, so for now i think let's not to modify it since it doesn’t have much impact.

ok，Understood, there is indeed a problem with that.it doesn't have any significant impact at the moment.