Activity for UNFS3
-
Karl Mikaelsson modified a wiki page
Home
-
Sorry for not getting back to you earlier - I've been swamped with other things at work. I just wanted to say that I haven't forgotten about this yet. The bad news is that I'll be away on vacation for almost a month, but I hope to get back to this when I return.
-
Rui Wang posted a comment on ticket #12
Thanks for reply. I did some research and I think I have found something. The function set_time() in attr.c use function utime() to change the timestamp of a file. When the target is a symlink file, utime() will follow the symlink, and if the symlink points to a non-existent file, utime() will return -1. I made a work around for my condition, but the patch code still has some limitation: the code can not determine if the nfs client wants to modify the symlink file itself or to follow the symlink...
-
Hi and thanks for the report! I will try to find time for looking into this problem later this week.
-
lutimes for symlink file failed with "Stale file handle"
-
Marc Siegel posted a comment on ticket #10
+1 sounds good @derfian For reference, here's a PR to homebrew-dinghy to change the UNFS3 dependency to your branch: https://github.com/codekitchen/homebrew-dinghy/pull/2
-
Sure, I will do that. I don't mind having the dinghy team depend on this branch until everything else settles into place.
-
No worries, I understand. In the meantime, would you be willing to commit to keeping your existing Github branch available at the same path? Could we temporarily make dinghy depend on that branch to build, to get Mac OS docker users back into good shape, and later change the dependency to be your next release?
-
I have a few portability concerns about the new code that I'd like to review before merging to master. Making a new release isn't at the top of my priority list at the moment.
-
Hi @derfian, ping on making a release ?
-
Since the nanosecond timestamps now work on your branch -- what is the process to make a release that includes this code?
-
Hurray! @derfian I've verified your fix! :) I have verifed by running Dinghy on Mac OS High Sierra (10.13.4). In order to verify your fix, I had to kill the fsevents_to_vm part of Dinghy, as that appears to have a separate issue with it. This leaves us with a Linux VM running in VirtualBox with boot2docker running inside, and mounting my home directory via your branch of unfs3. A. On Mac OS, run Dinghy with your branch of unfs3: # switch to my branch of homebrew-dinghy to use your branch of unfs3...
-
Hurray! @derfian I've verified your fix! :) I have verifed by running Dinghy on Mac OS High Sierra (10.13.4). In order to verify your fix, I had to kill the fsevents_to_vm part of Dinghy, as that appears to have a separate issue with it. This leaves us with a Linux VM running in VirtualBox with boot2docker running inside, and mounting my home directory via your branch of unfs3. A. On Mac OS, run Dinghy with your branch of unfs3: # switch to my branch of homebrew-dinghy to use your branch of unfs3...
-
Yep, that's it. I've pushed a new commit for this problem, thanks for letting me know.
-
@derfian, perhaps I am missing something, but it seems likely to me that we're simply missing at the top of clock_gettime.c the regular old: #include "config.h" I ask because I noticed that 1. Autoconf is detecting the presence of clock_gettime and therefore config.h is generated containing #define HAVE_CLOCK_GETTIME 1 2. clock_gettime.c is checking #ifndef HAVE_CLOCK_GETTIME, but this will always fail because it doesn't #include "config.h" Does the above make sense? Apologies of this is way off...
-
Thanks @derfian. On Mac OS High Sierra, I get a build failure: ==> make for i in Config ; do (cd $i && make all) || exit; done flex ./exports.l bison -y -d ./exports.y clang -g -O2 -Wall -W -I.. -I. -I.. -c -o lex.yy.o lex.yy.c clang -g -O2 -Wall -W -I.. -I. -I.. -c -o y.tab.o y.tab.c ar crs lib.a lex.yy.o y.tab.o clang -g -O2 -Wall -W -D_GNU_SOURCE -I. -c -o afsgettimes.o afsgettimes.c clang -g -O2 -Wall -W -D_GNU_SOURCE -I. -c -o afssupport.o afssupport.c clang -g -O2 -Wall -W -D_GNU_SOURCE -I....
-
I've pushed more commits to my branch, give it a try. I haven't really tested much, so it's the same as before. I'm mostly concerned with writing portable code. I don't think clock_gettime and struct timespec will be available on older platforms.
-
Support nano-second file timestamps
-
Thanks so much @derfian ! I've built your branch from github on Mac OS High Sierra and can verify that it at least compiles and runs. Please note: I am posting here because Issues are not enabled on your GitHub repo. Unfortunately, I've verified that when your branch of the unfs3 server is running on the Mac OS host, when a Ubuntu Linux client mounts the directory, it reports the nanosecond timestamps as still being all zero. For example, inside a Ubuntu container that has mounted the UNFS3 share...
-
To address the technical issues here, the NFS protocol supports nanosecond resolution timestamps. The issue with unfsd seems to be that the integration with the OS uses utime, which supports a resolution of seconds. There are other API:s (utimes, utimensat) which supports higher resolution timestamps (microseconds/nanoseconds). This looks to be an issue on all platforms, and not just macOS or High Sierra in particular. I've made a prototype of a fix on a branch over at github. I haven't really done...
-
I just pushed a new repo with the details on how I converted the SVN repo to Git. It was seriously annoying, so I don't want to do that again from scratch if I can avoid it. https://github.com/unfs3/unfs3-git-conversion
-
I wasn't aware there was a mirror. Github is what I've been thinking about anyway, and I've set up an organization for unfs3 here: https://github.com/unfs3
-
Feel free to submit pull requests against https://github.com/unfs3/unfs3
-
And secondly: If we were to develop a patch, how would we go about submitting it? Our extreme preference would be to develop as a Github pull request against the mirror repo there, as that is a workflow everyone is comfortable with and the development would be very public. If you don't control that repo, our second preference would be to create our own mirror on Github, and do the same there. But if the requirement is to email patches or whatever, I don't think there's any chance.
-
Thanks @karl. Sounds like it would be to say that this project is only mostly dead, then? Please let us know : our cursory understanding is that UNFS3 already supports nanosecond timestamps, and that the required fix would be to add support for this on APFS on Mac OS High Sierra only. We imagined that this would be taking the bits from other projects (such as go-lang) that added this support, and weaving them into the appriopriate places in UNFS3. Are these assumptions correct? Is it true that UNFS3...
-
Why not github, where people already use the mirror?
-
Move project away from Sourceforge
-
Hi there, unfs3 hasn't received much time and effort from myself and others over the last years, and while I really like to say that the maintainers (at least us from Cendio AB) have every intention to be facilitators for great, vibrant, open source projects. Then again, intentions are worthless - actions count. I can't refute your comments about patches and issues rotting in SourceForge. If that's your measure of dead, then I guess we're dead. :) If you or someone on your team is willing to contribute...
-
See also: https://github.com/codekitchen/dinghy/issues/269#issuecomment-381701748
-
IS THIS PROJECT ALIVE?
-
Yaakov Selkowitz posted a comment on ticket #9
As mentioned in the aforementioned bug reports, nfs-{cat,cp} do not exhibit this...
-
Peter Åstrand posted a comment on ticket #9
I've failed to reproduce this problem. Can you clarify what arguments you are calling...
-
READ procedure does not end with count==0
-
Paul Schutte modified a comment on ticket #8
some information got thrown out in the inline patch (asterisks) I attach the pat...
-
some information got thrown out in the mail. I attach the patch
-
Problem compiling against musl libc and libtirpc
-
Hannes Fuchs posted a comment on ticket #2
hi, do you still have this issue? i use unfs3 on centos7 and have maybe a similar...
-
Pierre Ossman modified ticket #7
build from source failed - r497
-
aaah, thx that was the trick. after "make clean" and rerun make it works.
-
That other bug is definitely interesting, but it isn't what's going on here. xdr_uint32...
-
attached (newly generated, but same error: rm config.h*; autoheader; ./configure;...
-
Sorry, I wasn't looking at the errors close enough. This was a linker error rather...
-
glibc-headers is installed (glibc-headers-2.17-78.el7.x86_64) attached the config.log...
-
Do you have glibc-headers installed? Could you share your config.log with us?
-
THX - tried, (config.h.in problem solved) but then i have the same problem as before...
-
THX - tried, but same problem as before with xdr - undefinied reference to xdr_uint32...
-
THX - tried, but same problem as before with xdr - undefinied reference to xfr_uint32...
-
You need to run the command autoheader to generate config.h.in. Grabbing an old one...
-
build from source failed - r497
-
Use an unsigned byte buffer for decoding 64 bit...
-
Stop using packed structures and type punning a...
-
Use a common header file for Windows errno names.
-
TheZeusJuice created ticket #6
Unexpected results when reading past the end of a directory's entries
-
UNFS3 released /OldFiles/mynfs-031222.tar.gz
-
-
-
-
-
-
-
-
-
-
-
-
Always truncate fsid to a 32-bit value, even th...
-
Add myself and Jason to CREDITS
-
Fix these warnings:
-
Call access to respect ACL:s
-
Jason Wessel created ticket #5
Fixes and improvements from the Yocto Project
