Skip to content
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

POSIX file watching doesn't get notified when files are transfered using VOS #103

Open
sefffal opened this issue Jul 9, 2021 · 8 comments

Comments

@sefffal
Copy link

sefffal commented Jul 9, 2021

Low priority bug / feature request:

I created a script using Julia's watch_folder function to trigger an action when a file is added to a given directory. Testing using linux commands on the science platform e.g. tough text.txt triggers events, but transferring files using vcp does not. The files appear immediately using ls but no event is generated.

@andamian
Copy link
Contributor

andamian commented Jul 9, 2021

What is the feature request/bug here? Is the vcp command triggered?

@sefffal
Copy link
Author

sefffal commented Jul 9, 2021

Brian asked me to open this.

When we copy files using vcp to arc, scripts watching that folder for changes are not triggered. The request is for vcp to notify on file changes using the standard system on linux (inotify I believe, see man page https://man7.org/linux/man-pages/man7/inotify.7.html)

@andamian
Copy link
Contributor

andamian commented Jul 9, 2021

Still don't understand what is missing in vcp. If I understand correctly, you copy a file to arc using vcp but inotify is not triggered. Is the directory under watched mounted to arc? Does it work when you upload the file via the Web GUI? Am I misunderstanding the problem here? If so, please provide more details. Thanks

@andamian
Copy link
Contributor

@brianmajor - can you comment more on this?

@sefffal
Copy link
Author

sefffal commented Jul 12, 2021

Yes, it is mounted to arc.
I am a user running a notebook on the science platform. Arc is mounted and I can access files under /arc/projects/...

I wrote a script that watches for changes to a directory in projects. If I run touch test.txt on the science platform, this change is picked up by the script (I presume through inotify, but this is beyond me to test).

If I instead copy a file to that directory remotely using e.g. vcp the file gets added silently and the script is not triggered.

I had a use case for this functionality last weekend while observing. As data was transferred from the telescope to our projects directory, the script would have picked up the new files and triggered a live analysis of the data.

This is not essential functionality and we were able to work around it, but I reported it in case inotify was already expected to work.

@andamian
Copy link
Contributor

This is not a vcp issue for sure as vcp has no control over that storage FS. It could be a problem with the arc VOSpace service (which Brian is more familiar with) or with the sshfs mounting. Have you tried to manually copy a file into the directory that's being monitored but using the mount point instead of vcp. If that works then it's a problem with arc and the issue should be opened in a different repo (I can assist you with that). Let me know how it works.

@brianmajor
Copy link
Member

Yes, I guess since it's a remote upload (rather than a local download) using vcp then it probably is an issue in cavern, not the tool. I'll move this over to vos.git/cavern. Thanks for reporting.

@brianmajor brianmajor transferred this issue from opencadc/vostools Jul 12, 2021
@pdowler
Copy link
Member

pdowler commented Jan 31, 2024

wild guess: when you put a file, it initially gets created as root and then chown-ed to the user. Does the notify mechanism care about who owns the file when it is created? or somehow not get triggered by root?

I don't think I could find an atomic "create+chown" functionality in the java nio library, but I could dig deeper or probably fake it out by creating the file in another location, chown, then atomic move to the right location in the directory. That would have some side benefits of not leaving a file in an intermediate and possibly broken state if something fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants