SeaDrive 3.0.9 File uploaded to wrong folder when create and modify folder name

  1. Environment:
    SeaDrive v3.0.9 on MacOS 14.5
    SeaFile Server v10.0.8
    Encrypted Library

  2. Step:
    2.1 Create Encrypted Library
    2.2 Create New Folder in encrypted library, the default name is 「未命名文件夹」. SeaDrive will automatic upload
    Here is the stat -s of folder:

st_dev=16777229 st_ino=34507599 st_mode=040755 st_nlink=2 st_uid=501 st_gid=20 st_rdev=0 st_size=64 st_atime=1718766691 st_mtime=1718766691 st_ctime=1718766691 st_birthtime=1718766691 st_blksize=4096 st_blocks=0 st_flags=0

2.3 Modify folder name to 「test1」 and SeaDrive will automatic upload
Here is the stat -s of folder:

st_dev=16777229 st_ino=34507599 st_mode=040755 st_nlink=2 st_uid=501 st_gid=20 st_rdev=0 st_size=64 st_atime=1718766691 st_mtime=1718766691 st_ctime=1718766694 st_birthtime=1718766691 st_blksize=4096 st_blocks=0 st_flags=0

2.4 Copy file test2.log to folder 「test1」
Here is the stat -s of folder:

st_dev=16777229 st_ino=34507599 st_mode=040755 st_nlink=3 st_uid=501 st_gid=20 st_rdev=0 st_size=96 st_atime=1718766696 st_mtime=1718766696 st_ctime=1718766696 st_birthtime=1718766691 st_blksize=4096 st_blocks=0 st_flags=0

After these steps, the folder in local is:
./test1
./test1/test2.log

Bug the folder in cloud is:
./test1
./未命名文件夹
./未命名文件夹/test2.log

I cannot reproduce the issue with latest SeaDrive and macOS14.5. It should be some special local issues. Can you check events.log for which events are detected? Also check the seadrive.log for the log messages when you make the operations.

Here is the events.log when issue happened.

[06/19/24 11:11:33] Space 1c1dbc18-f6bf-424e-b668-87703c581955 0e561f6beeed81078b8c3271a96969b13da1fec2
[event 1] create/update, test/未命名文件夹
[06/19/24 11:11:38] Space 1c1dbc18-f6bf-424e-b668-87703c581955 d1331c82ddebc002396637e4090d1d72262013cd
[event 1] rename, test/未命名文件夹 test/test1
[event 2] create/update, test/未命名文件夹/test2.log

Here is the seadrive.log when issue happened.

[06/19/24 11:11:33] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘synchronized’ to ‘committing’.
[06/19/24 11:11:33] sync-mgr-mac.c(1140): All events are processed for repo 1c1dbc18-f6bf-424e-b668-87703c581955.
[06/19/24 11:11:33] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘committing’ to ‘uploading’.
[06/19/24 11:11:33] http-tx-mgr.c(4486): Upload with HTTP sync protocol version 2.
[06/19/24 11:11:33] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘init’) → (‘normal’, ‘check’)
[06/19/24 11:11:33] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘check’) → (‘normal’, ‘commit’)
[06/19/24 11:11:33] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘commit’) → (‘normal’, ‘fs’)
[06/19/24 11:11:33] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘fs’) → (‘normal’, ‘data’)
[06/19/24 11:11:33] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘data’) → (‘normal’, ‘update-branch’)
[06/19/24 11:11:33] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘update-branch’) → (‘finished’, ‘finished’)
[06/19/24 11:11:33] sync-mgr.c(3458): removing blocks for repo 1c1dbc18-f6bf-424e-b668-87703c581955
[06/19/24 11:11:33] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘uploading’ to ‘get sync info’.
[06/19/24 11:11:33] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘get sync info’ to ‘synchronized’.
[06/19/24 11:11:38] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘synchronized’ to ‘committing’.
[06/19/24 11:11:38] sync-mgr-mac.c(1140): All events are processed for repo 1c1dbc18-f6bf-424e-b668-87703c581955.
[06/19/24 11:11:38] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘committing’ to ‘uploading’.
[06/19/24 11:11:38] http-tx-mgr.c(4486): Upload with HTTP sync protocol version 2.
[06/19/24 11:11:38] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘init’) → (‘normal’, ‘check’)
[06/19/24 11:11:38] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘check’) → (‘normal’, ‘commit’)
[06/19/24 11:11:38] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘commit’) → (‘normal’, ‘fs’)
[06/19/24 11:11:38] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘fs’) → (‘normal’, ‘data’)
[06/19/24 11:11:38] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘data’) → (‘normal’, ‘update-branch’)
[06/19/24 11:11:38] http-tx-mgr.c(1342): Transfer repo ‘1c1dbc18’: (‘normal’, ‘update-branch’) → (‘finished’, ‘finished’)
[06/19/24 11:11:38] sync-mgr.c(3458): removing blocks for repo 1c1dbc18-f6bf-424e-b668-87703c581955
[06/19/24 11:11:38] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘uploading’ to ‘get sync info’.
[06/19/24 11:11:38] sync-mgr.c(1026): Repo ‘Space’ sync state transition from ‘get sync info’ to ‘synchronized’.

It seems the 「rename」and 「create」events produced at the same time.
BTW, this issue only happened when create file quickly after rename folder.

This is a known issue. This only happens in some cases and cannot be reproduced reliably on every OS. It seems that the OS behavior is also changed from time to time. As it’s not quite easy to fix without causing other issue (such as blocking other operations) we’re still thinking about a good solution.

Do you have any workaround to avoid this issue?

The current work around is to avoid create a new folder and create file in it in short time.

This is fixed in 3.0.11.