-
Notifications
You must be signed in to change notification settings - Fork 0
DA-992: Pair windows' delete + create event to generate a rename event #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
In these imperfect cases, how would drive handle it? |
|
ianyh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just stylistic comments I already had, but holding off on the rest of the review as we discussed.
6610dff to
9e1651b
Compare
hu13
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some stylist comments.
I still want to discuss the main logic interactively since I don't fully understand some of it.
| mask = sysFSDELETESELF | ||
| case syscall.FILE_ACTION_MODIFIED: | ||
| mask = sysFSMODIFY | ||
| case syscall.FILE_ACTION_RENAMED_OLD_NAME: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like in this case you don't set mask.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I guess this is just relying on the variable initializing by default to 0 so the ands do the right thing.
windows.go
Outdated
| if watch.rename != "" { | ||
| if w.sendEvent("", watch.names[name]&mask, watch.rename) { | ||
| if watch.names[name]&sysFSONESHOT != 0 { | ||
| delete(watch.names, name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to return in this case? Otherwise we send two events.
* Let's begin * Add getpath * Init test workflow * 1.40.0 exits? * Linter fix * asdf * 100 Co-authored-by: hu13 <[email protected]>
#1) * made the changes related to recursive directory check * made changes in window.go for buffer size * added the oldname attribute * old name added to rename event, one event is generated for rename * added oldname in printing rename events * tests for checking the oldName attr for rename added * create fsnotify event added * input to create event changed * create fsnotify event function modified * ID added * logs added * added create fsnotify event in inotify * logs added * prints added * reviews * reviews addressed * Hangkun/da 992/window rename event (#2) * Let's begin * Add getpath * Init test workflow * 1.40.0 exits? * Linter fix * asdf * 100 Co-authored-by: hu13 <[email protected]> * Clean up unused * Badge Co-authored-by: Hangkun Ung <[email protected]> Co-authored-by: hu13 <[email protected]>
* introduce GitHub Actions * Add lint+vet+old versions to GitHub Action * Remove Travis CI and references * Drop support/testing for Go 1.11 and earlier (fsnotify#381) * Update x/sys to latest (fsnotify#379) * add //go:build lines + add 1.17.0-rc2 to test matrix (fsnotify#377) * Update test matrix for go 1.17 stable release (fsnotify#385) * Add AddRaw to not follow symlinks + Fix link folloing on Windows (fsnotify#289) * v1.5.0 preparation (fsnotify#380) * revise pull request template * Revert "Add AddRaw to not follow symlinks + Fix link folloing on Windows (fsnotify#289)" This reverts commit e2e9517. * prepare 1.5.1, retract 1.5.0 * Removed dead link * Update issue templates (fsnotify#410) * Update issue templates * remove old issue template * Test on Go 1.18 and two most recent versions (fsnotify#411) * Test on Go 1.18 and two most recent versions * on push * ci * update readme * revise contributing * maintainers wanted * Final Notice: Maintainers Wanted * fix go vet warnings: call to (*T).Fatalf from a non-test goroutine (fsnotify#416) * made the changes related to recursive directory check * made changes in window.go for buffer size * DA-992: Pair windows' delete + create event to generate a rename event (#1) * made the changes related to recursive directory check * made changes in window.go for buffer size * added the oldname attribute * old name added to rename event, one event is generated for rename * added oldname in printing rename events * tests for checking the oldName attr for rename added * create fsnotify event added * input to create event changed * create fsnotify event function modified * ID added * logs added * added create fsnotify event in inotify * logs added * prints added * reviews * reviews addressed * Hangkun/da 992/window rename event (#2) * Let's begin * Add getpath * Init test workflow * 1.40.0 exits? * Linter fix * asdf * 100 Co-authored-by: hu13 <[email protected]> * Clean up unused * Badge Co-authored-by: Hangkun Ung <[email protected]> Co-authored-by: hu13 <[email protected]> * Rebase upstream fixes * Rename bundle only works on windows * Update CI golang Co-authored-by: Ichinose Shogo <[email protected]> Co-authored-by: Oliver Bristow <[email protected]> Co-authored-by: Nahum Shalman <[email protected]> Co-authored-by: Nathan Youngman <[email protected]> Co-authored-by: Loïc Vernet <[email protected]> Co-authored-by: Nathan Youngman <[email protected]> Co-authored-by: paris <[email protected]> Co-authored-by: hu13 <[email protected]>
Jira: DA-992
For each rename action on a file, two syscall event is generated:
1-
FILE_ACTION_RENAMED_OLD_NAMEand2-
FILE_ACTION_RENAMED_NEW_NAME.Here I assumed that the first one is followed by the second one.
Then one fsnorify RENAME event is generated.
RENAME event has the file's oldName set up.
the
OldNameattribute is added to theEventstruct of fsnotify.The system call of
FILE_ACTION_RENAMED_OLD_NAMEholds the file's old name. Upon receiving this syscall event,watcher.renameis set up with the file's old name which serves as a state variable. No fsnotify event is created.The system call of
FILE_ACTION_RENAMED_NEW_NAMEholds the file's new name. A RENAME fsnotify event is created with file's old name,watcher.rename, asOldNameattribute .Cases:
receive
FILE_ACTION_RENAMED_NEW_NAMEandwatcher.renamehas a value, perfect case, a RENAME event is generated.receive any syscall rather than
FILE_ACTION_RENAMED_NEW_NAMEandwatcher.renamehas a value, first a RENAME event is created with empty name and the OldName iswatcher.renamevalue, then the syscall event is handled.receive
FILE_ACTION_RENAMED_NEW_NAMEandwatcher.renamehas no value, a RENAME event is generated with an empty oldName.Tests:
in imtegration_test.go
TestFsnotifyMultipleRenames():
generates 1000 rename action and checks if the RENAME attribute is set up correctly and all of the events are received.
TestFsnotifyRenameEventAttributes():
Checks if the
OldNameattribute is set up correctly for a rename event