Open seiman opened 5 years ago
I can observe the same in the latest main
code, macOS Ventura.
Further down in the log I get this, where afpd detects a file create request for the same file:
Apr 08 13:37:00 rasp32 afpd[8577]: cname_mtouname('afpd-icon copy.bmp',did:2) {demangled:'afpd-icon copy.bmp', fileid:0}
Apr 08 13:37:00 rasp32 afpd[8577]: cname('/home/dmark/afp-data'): {node: 'afpd-icon copy.bmp}
Apr 08 13:37:00 rasp32 afpd[8577]: of_stat('/home/dmark/afp-data/afpd-icon copy.bmp': No such file or directory)
Apr 08 13:37:00 rasp32 afpd[8577]: cname('/home/dmark/afp-data'): {leave-cnode ENOENT (probably create request): 'afpd-icon copy.bmp'}
Apr 08 13:37:00 rasp32 afpd[8577]: cname('/home/dmark/afp-data') {end: curdir:'/home/dmark/afp-data', path:'afpd-icon copy.bmp'}
Apr 08 13:37:00 rasp32 afpd[8577]: getfildirparams(vid:1, did:2, f/d:e93f/a33f) {cwdid:2, cwd: /home/dmark/afp-data, name:'afpd-icon copy.bmp'}
Apr 08 13:37:00 rasp32 afpd[8577]: ==> Finished AFP command: AFP_GETFLDRPARAM -> AFPERR_NOOBJ
But FCE doesn't seem to be aware according to the logs.
@seiman Were you attempting to address this issue with your PRs in https://github.com/Netatalk/netatalk/pull/98 and https://github.com/Netatalk/netatalk/pull/99 by any chance?
Unfortunately the improvements in https://github.com/Netatalk/netatalk/pull/849 didn't actually address this particular issue (although they improved other scenarios.)
Using the duplicate function of the finder (⌘+d) leads to the fce events
afpd[43] {fce_api.c:533} (debug:FCE): register_fce(path: /media/share/P00002315572 Kopie.jpg, event: FCE_FILE_CREATE)
afpd[43] {fce_api.c:533} (debug:FCE): register_fce(path: /media/share/P00002315572 Kopie.jpg, event: FCE_FILE_DELETE)
We assume, that the file is first being created, then deleted, then created again and modified, but only events for the first two operations are being created.
Tested on MacOs 10.12.6 and 10.14.5