aboutsummaryrefslogtreecommitdiff
path: root/tests/sys/fs
Commit message (Collapse)AuthorAgeFilesLines
* fusefs tests: quell Coverity "Argument cannot be negative" warningsAlan Somers2020-10-029-55/+55
| | | | | | | | | | | | | Must abort tests early if open(2) fails. Reported by: Coverity Coverity CID: 1432810 and many others Reviewed by: kevans MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D26635 Notes: svn path=/head/; revision=366365
* Do a sweep and remove most WARNS=6 settingsKyle Evans2020-10-011-2/+0
| | | | | | | | | | | | | | | Repeating the default WARNS here makes it slightly more difficult to experiment with default WARNS changes, e.g. if we did something absolutely bananas and introduced a WARNS=7 and wanted to try lifting the default to that. Drop most of them; there is one in the blake2 kernel module, but I suspect it should be dropped -- the default WARNS in the rest of the build doesn't currently apply to kernel modules, and I haven't put too much thought into whether it makes sense to make it so. Notes: svn path=/head/; revision=366304
* fusefs: fix mmap'd writes in direct_io modeAlan Somers2020-09-241-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | If a FUSE server returns FOPEN_DIRECT_IO in response to FUSE_OPEN, that instructs the kernel to bypass the page cache for that file. This feature is also known by libfuse's name: "direct_io". However, when accessing a file via mmap, there is no possible way to bypass the cache completely. This change fixes a deadlock that would happen when an mmap'd write tried to invalidate a portion of the cache, wrongly assuming that a write couldn't possibly come from cache if direct_io were set. Arguably, we could instead disable mmap for files with FOPEN_DIRECT_IO set. But allowing it is less likely to cause user complaints, and is more in keeping with the spirit of open(2), where O_DIRECT instructs the kernel to "reduce", not "eliminate" cache effects. PR: 247276 Reported by: trapexit@spawn.link Reviewed by: cem MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D26485 Notes: svn path=/head/; revision=366121
* fusefs: fix the FUSE_FORGET unit test after r364064Alan Somers2020-08-111-1/+2
| | | | | | | | | | | | Thanks to r364064, the name cache now returns a hit where previously it would miss. Adjust the expectations accordingly. PR: 248583 Reported by: lwhsu MFC with: r364064 Notes: svn path=/head/; revision=364094
* Fix issues with FUSE_ACCESS when default_permissions is disabledAlan Somers2020-05-227-90/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two issues relating to FUSE_ACCESS when the default_permissions mount option is disabled: * VOP_ACCESS() calls with VADMIN set should never be sent to a fuse server in the form of FUSE_ACCESS operations. The FUSE protocol has no equivalent of VADMIN, so we must evaluate such things kernel-side, regardless of the default_permissions setting. * The FUSE protocol only requires FUSE_ACCESS to be sent for two purposes: for the access(2) syscall and to check directory permissions for searchability during lookup. FreeBSD sends it much more frequently, due to differences between our VFS and Linux's, for which FUSE was designed. But this patch does eliminate several cases not required by the FUSE protocol: * for any FUSE_*XATTR operation * when creating a new file * when deleting a file * when setting timestamps, such as by utimensat(2). * Additionally, when default_permissions is disabled, this patch removes one FUSE_GETATTR operation when deleting a file. PR: 245689 Reported by: MooseFS FreeBSD Team <freebsd@moosefs.pro> Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24777 Notes: svn path=/head/; revision=361401
* fusefs: fix intermittency in some ENOENT testsAlan Somers2020-05-183-0/+35
| | | | | | | | | | | | | When a FUSE operation other than LOOKUP returns ENOENT, the kernel will reclaim that vnode, resuling in a FUSE_FORGET being sent a short while later. Many of the ENOENT tests weren't expecting those FUSE_FORGET operations. They usually passed by luck since FUSE_FORGET is often delayed. This commit adds appropriate expectations. MFC after: 2 weeks Notes: svn path=/head/; revision=361223
* fusefs: fix two small bugs in the tests' expectationsAlan Somers2020-05-082-2/+2
| | | | | | | | | | | These two errors have been present since the tests' introduction. Coincidentally every test (I think there's only one) that cares about that field also works when the field's value is 0. MFC after: 2 weeks Notes: svn path=/head/; revision=360829
* Resolve conflict between the fusefs(5) and mac_bsdextended(4) testsAlan Somers2020-05-021-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mac_bsdextended(4), when enabled, causes ordinary operations to send many more VOP_GETATTRs to file system. The fusefs tests expectations aren't written with those in mind. Optionally expecting them would greatly obfuscate the fusefs tests. Worse, certain fusefs functionality (like attribute caching) would be impossible to test if the tests couldn't expect an exact number of GETATTR operations. This commit resolves that conflict by making two changes: 1. The fusefs tests will now check for mac_bsdextended, and skip if it's enabled. 2. The mac_bsdextended tests will now check whether the module is enabled, not merely loaded. If it's loaded but disabled, the tests will automatically enable it for the duration of the tests. With these changes, a CI system can achieve best coverage by loading both fusefs and mac_bsdextended at boot, and setting security.mac.bsdextended.enabled=0 PR: 244229 Reported by: lwhsu Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24577 Notes: svn path=/head/; revision=360567
* fusefs: avoid cache corruption with buggy fuse serversAlan Somers2020-03-116-22/+244
| | | | | | | | | | | | | | | | | | | The FUSE protocol allows the client (kernel) to cache a file's size, if the server (userspace daemon) allows it. A well-behaved daemon obviously should not change a file's size while a client has it cached. But a buggy daemon might. If the kernel ever detects that that has happened, then it should invalidate the entire cache for that file. Previously, we would not only cache stale data, but in the case of a file extension while we had the size cached, we accidentally extended the cache with zeros. PR: 244178 Reported by: Ben RUBSON <ben.rubson@gmx.com> Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24012 Notes: svn path=/head/; revision=358867
* fusefs: fix fsync for files with multiple open handlesAlan Somers2020-03-091-4/+31
| | | | | | | | | | | | | | We were reusing a structure for multiple operations, but failing to reinitialize one member. The result is that a server that cares about FUSE file handle IDs would see one correct FUSE_FSYNC operation, and one with the FHID unset. PR: 244431 Reported by: Agata <chogata@gmail.com> MFC after: 2 weeks Notes: svn path=/head/; revision=358798
* [skip ci] fix typo in comment in the fusefs testsAlan Somers2020-03-091-1/+1
| | | | | | | MFC after: 2 weeks Notes: svn path=/head/; revision=358797
* [skip ci] delete obsolete comment in fusefs testsAlan Somers2020-02-191-3/+0
| | | | | | | | | It should've been deleted by r349436 MFC after: 2 weeks Notes: svn path=/head/; revision=358089
* fusefs: fix some memory leaks in the tests.Alan Somers2020-02-122-0/+8
| | | | | | | | | | | Oddly, most of these were not detected by Coverity. Reported by: Coverity (one of them, anyway) Coverity CID: 1404490 MFC after: 2 weeks Notes: svn path=/head/; revision=357835
* tests: fusefs: silence remaining unsigned/signed comparison warningsKyle Evans2020-01-101-3/+3
| | | | | | | | | | External GCC turns these into errors; cast to long to silence them. Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D23127 Notes: svn path=/head/; revision=356614
* Refine fusefs test workaround for mips+llvmKyle Evans2020-01-061-0/+5
| | | | | | | | | | | | | | | | | | | | This re-enables building the googletest suite by default on mips and instead specifically doesn't build fusefs tests for mips+clang builds. clang will easily spent >= 1.5 hours compiling a single file due to a bug in optimization (see LLVM PR 43263), so turn these off for now while that's hashed out. GCC builds are unaffected and build the fusefs tests as-is. Clang builds only happen by early adopters attempting to hash out the remaining issues. The comment has been updated to reflect its new position and use less strong wording about imposing on people. Discussed with: ngie, asomers Reviewed by: ngie Notes: svn path=/head/; revision=356423
* fusefs: initialize C++ classes the Coverity wayAlan Somers2019-09-162-3/+6
| | | | | | | | | | | | | Coverity complained that I wasn't initializing some class members until the SetUp method. Do it in the constructor instead. Reported by: Coverity Coverity CIDs: 1404352, 1404378 MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=352414
* fusefs: fix some minor Coverity CIDs in the testsAlan Somers2019-09-163-4/+4
| | | | | | | | | | | | | | Where open(2) is expected to fail, the tests should assert or expect that its return value is -1. These tests all accepted too much but happened to pass anyway. Reported by: Coverity Coverity CID: 1404512, 1404378, 1404504, 1404483 MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=352413
* fusefs: Fix iosize for FUSE_WRITE in 7.8 compat modeAlan Somers2019-09-112-51/+92
| | | | | | | | | | | | | | | | | When communicating with a FUSE server that implements version 7.8 (or older) of the FUSE protocol, the FUSE_WRITE request structure is 16 bytes shorter than normal. The protocol version check wasn't applied universally, leading to an extra 16 bytes being sent to such servers. The extra bytes were allocated and bzero()d, so there was no information disclosure. Reviewed by: emaste MFC after: 3 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21557 Notes: svn path=/head/; revision=352230
* fusefs: suppress some Coverity resource leak CIDs in the testsAlan Somers2019-09-071-0/+1
| | | | | | | | | | | | | The fusefs tests deliberately leak file descriptors. To do otherwise would add extra complications to the tests' mock FUSE server. This annotation should hopefully convince Coverity to shut up about the leaks. Reviewed by: uqs MFC after: 4 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=352021
* fusefs: coverity cleanup in the testsAlan Somers2019-09-0618-33/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address the following defects reported by Coverity: * Structurally dead code (CID 1404366): set m_quit before FAIL, not after * Unchecked return value of sysctlbyname (CID 1404321) * Unchecked return value of stat(2) (CID 1404471) * Unchecked return value of open(2) (CID 1404402, 1404529) * Unchecked return value of dup(2) (CID 1404478) * Buffer overflows. These are all false positives caused by the fact that Coverity thinks I'm using a buffer to store strings, when in fact I'm really just using it to store a byte array that happens to be initialized with a string. I'm changing the type from char to uint8_t in the hopes that it will placate Coverity. (CID 1404338, 1404350, 1404367, 1404376, 1404379, 1404381, 1404388, 1404403, 1404425, 1404433, 1404434, 1404474, 1404480, 1404484, 1404503, 1404505) * False positive file descriptor leak. I'm going to try to fix this with Coverity modeling, but I'll also change an EXPECT to ASSERT so we don't perform meaningless assertions after the failure. (CID 1404320, 1404324, 1404440, 1404445). * Unannotated file descriptor leak. This will be followed up by a Coverity modeling change. (CID 1404326, 1404334, 1404336, 1404357, 1404361, 1404372, 1404391, 1404395, 1404409, 1404430, 1404448, 1404451, 1404455, 1404457, 1404458, 1404460) * Uninitialized variables in C++ constructors (CID 1404327, 1404346). In the case of m_maxphys, this actually led to part of the FUSE_INIT's response being set to stack garbage during the WriteCluster::clustering test. * Uninitialized sun_len field in struct sockaddr_un (CID 1404330, 1404371, 1404429). Reported by: Coverity Reviewed by: emaste MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21457 Notes: svn path=/head/; revision=351963
* fusefs: Fix some bugs regarding the size of the LISTXATTR listAlan Somers2019-08-282-40/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * A small error in r338152 let to the returned size always being exactly eight bytes too large. * The FUSE_LISTXATTR operation works like Linux's listxattr(2): if the caller does not provide enough space, then the server should return ERANGE rather than return a truncated list. That's true even though in FUSE's case the kernel doesn't provide space to the client at all; it simply requests a maximum size for the list. We previously weren't handling the case where the server returns ERANGE even though the kernel requested as much size as the server had told us it needs; that can happen due to a race. * We also need to ensure that a pathological server that always returns ERANGE no matter what size we request in FUSE_LISTXATTR won't cause an infinite loop in the kernel. As of this commit, it will instead cause an infinite loop that exits and enters the kernel on each iteration, allowing signals to be processed. Reviewed by: cem MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21287 Notes: svn path=/head/; revision=351560
* Fix the build with WITHOUT_GOOGLETESTKyle Evans2019-08-221-1/+3
| | | | | | | | | | | | | Attempting to build the fusefs tests WITHOUT_GOOGLETEST will result in an error if the host system or sysroot doesn't already have googletest headers in /usr/include/private (e.g. host built/installed WITHOUT_GOOGLETEST, clean cross-buildworld WITHOUT_GOOGLETEST). Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D21367 Notes: svn path=/head/; revision=351399
* fusefs: don't send the namespace during listextattrAlan Somers2019-08-161-6/+3
| | | | | | | | | | | | | | | | | | The FUSE_LISTXATTR operation always returns the full list of a file's extended attributes, in all namespaces. There's no way to filter the list server-side. However, currently FreeBSD's fusefs driver sends a namespace string with the FUSE_LISTXATTR request. That behavior was probably copied from fuse_vnop_getextattr, which has an attribute name argument. It's been there ever since extended attribute support was added in r324620. This commit removes it. Reviewed by: cem MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21280 Notes: svn path=/head/; revision=351113
* fusefs: fix conditional from r351061Alan Somers2019-08-151-2/+1
| | | | | | | | | | | | | | | The entirety of r351061 was a copy/paste error. I'm sorry I've been comitting so hastily. Reported by: rpokala Reviewed by: rpokala MFC after: 2 weeks MFC-With: 351061 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21265 Notes: svn path=/head/; revision=351066
* fusefs: fix the 32-bit build after 351042Alan Somers2019-08-151-1/+2
| | | | | | | | | | Reported by: jhb MFC after: 2 weeks MFC-With: 351042 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=351061
* fusefs: Fix the size of fuse_getattr_inAlan Somers2019-08-143-0/+160
| | | | | | | | | | | | | | | | | | In FUSE protocol 7.9, the size of the FUSE_GETATTR request has increased. However, the fusefs driver is currently not sending the additional fields. In our implementation, the additional fields are always zero, so I there haven't been any test failures until now. But fusefs-lkl requires the request's length to be correct. Fix this bug, and also enhance the test suite to catch similar bugs. PR: 239830 MFC after: 2 weeks MFC-With: 350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=351042
* fusefs: fix intermittency in the default_permissions.Unlink.ok testAlan Somers2019-08-141-0/+8
| | | | | | | | | | | | | The test needs to expect a FUSE_FORGET operation. Most of the time the test would pass anyway, because by chance FUSE_FORGET would arrive after the unmount. MFC after: 2 weeks MFC-With: 350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=351039
* fusefs: skip some tests when unsafe aio is disabledAlan Somers2019-08-136-21/+38
|\ | | | | | | | | | | | | | | | | MFC after: 15 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=350992
| * fusefs: skip some tests when unsafe aio is disabledAlan Somers2019-08-126-21/+38
| | | | | | | | | | | | | | | | | | MFC after: 16 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350955
* | fusefs: add SVN Keywords to the test filesAlan Somers2019-08-1343-0/+86
| | | | | | | | | | | | | | | | | | | | Reported by: SVN pre-commit hooks MFC after: 15 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=350990
* | Don't add -Wno-class-memaccess with older gcc.Brooks Davis2019-08-091-1/+6
|/ | | | | | | | | | | | | This is a gcc 8.0+ warning which needed to be silenced on for the riscv build. amd64-xtoolchain-gcc still uses gcc 6.4.0 and does not understand this flag. Reviewed by: asomers Feedback from: imp Differential Revision: https://reviews.freebsd.org/D21195 Notes: svn path=/head/; revision=350827
* fusefs: fix building tests with GCC 8Alan Somers2019-07-301-1/+1
| | | | | | | | | GCC 8 objected to including C++-only flags in CWARNFLAGS Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350455
* fusefs: nul-terminate some strings in the readdir testAlan Somers2019-07-301-8/+8
| | | | | | | | Reported by: GCC 8 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350452
* fusefs: fix panic when writing with O_DIRECT and using writeback cacheAlan Somers2019-07-281-0/+126
| | | | | | | | | | | | When a fusefs file system is mounted using the writeback cache, the cache may still be bypassed by opening a file with O_DIRECT. When writing with O_DIRECT, the cache must be invalidated for the affected portion of the file. Fix some panics caused by inadvertently invalidating too much. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350388
* fusefs: fix warnings in the tests reported by GCCAlan Somers2019-07-2019-79/+88
| | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350163
* sendfile: don't panic when VOP_GETPAGES_ASYNC returns an errorAlan Somers2019-07-191-1/+1
| | | | | | | | PR: 236466 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350144
* fusefs: add a intr/nointr mount optionAlan Somers2019-07-185-12/+79
| | | | | | | | | | | | | | | | | | | | | | | FUSE file systems can optionally support interrupting outstanding operations. However, the file system does not identify to the kernel at mount time whether it's capable of doing that. Instead it signals its noncapability by returning ENOSYS to the first FUSE_INTERRUPT operation it receives. That's a problem for reliable signal delivery, because the kernel must choose which thread should get a signal before it knows whether the FUSE server can handle interrupts. The problem is even worse because the FUSE protocol allows a file system to simply ignore all FUSE_INTERRUPT operations. Fix the signal delivery logic by making interruptibility an opt-in mount option. This will require a corresponding change to libfuse, but not to most file systems that link to libfuse. Bump __FreeBSD_version due to the new mount option. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350115
* fusefs: multiple interruptility improvementsAlan Somers2019-07-171-59/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Don't explicitly not mask SIGKILL. kern_sigprocmask won't allow it to be masked, anyway. 2) Fix an infinite loop bug. If a process received both a maskable signal lower than 9 (like SIGINT) and then received SIGKILL, fticket_wait_answer would spin. msleep would immediately return EINTR, but cursig would return SIGINT, so the sleep would get retried. Fix it by explicitly checking whether SIGKILL has been received. 3) Abandon the sig_isfatal optimization introduced by r346357. That optimization would cause fticket_wait_answer to return immediately, without waiting for a response from the server, if the process were going to exit anyway. However, it's vulnerable to a race: 1) fatal signal is received while fticket_wait_answer is sleeping. 2) fticket_wait_answer sends the FUSE_INTERRUPT operation. 3) fticket_wait_answer determines that the signal was fatal and returns without waiting for a response. 4) Another thread changes the signal to non-fatal. 5) The first thread returns to userspace. Instead of exiting, the process continues. 6) The application receives EINTR, wrongly believes that the operation was successfully interrupted, and restarts it. This could cause problems for non-idempotent operations like FUSE_RENAME. Reported by: kib (the race part) Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350097
* projects/fuse2: build fixesAlan Somers2019-07-131-2/+2
| | | | | | | | | | * Fix the kernel build with gcc by removing a redundant extern declaration * In the tests, fix a printf format specifier that assumed LP64 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349970
* fusefs: don't leak memory of unsent operations on unmountAlan Somers2019-06-281-0/+93
| | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349513
* fusefs: recycle vnodes after their last unlinkAlan Somers2019-06-272-13/+159
| | | | | | | | | | | | Previously fusefs would never recycle vnodes. After VOP_INACTIVE, they'd linger around until unmount or the vnlru reclaimed them. This commit essentially actives and inlines the old reclaim_revoked sysctl, and fixes some issues dealing with the attribute cache and multiply linked files. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349468
* fusefs: fix a memory leak in the forget testAlan Somers2019-06-271-0/+1
| | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349464
* fusefs: tighten expectations in mmap testsAlan Somers2019-06-261-7/+4
| | | | | | | | | In r349378 I fixed mmap's habit of reading more data than was available. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349445
* fusefs: annotate deliberate file descriptor leaks in the testsAlan Somers2019-06-2618-101/+128
| | | | | | | | | | | | | | closing a file descriptor causes FUSE activity that is superfluous to the purpose of most tests, but would nonetheless require matching expectations. Rather than do that, most tests deliberately leak file descriptors instead. This commit moves the leakage from each test into two trivial functions: leak and leakdir. Hopefully Coverity will only complain about those functions and not all of their callers. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349440
* fusefs: run the io tests with direct io, tooAlan Somers2019-06-261-11/+56
| | | | | | | | | | | | Now the io tests are run in all cache modes. The fusefs test suite can now get adequate coverage without changing the value of vfs.fusefs.data_cache_mode, which is only needed for legacy file systems now. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349436
* fusefs: implement protocol 7.23's FUSE_WRITEBACK_CACHE optionAlan Somers2019-06-265-123/+39
| | | | | | | | | | | | | | | | | | | | | | As of protocol 7.23, fuse file systems can specify their cache behavior on a per-mountpoint basis. If they set FUSE_WRITEBACK_CACHE in fuse_init_out.flags, then they'll get the writeback cache. If not, then they'll get the writethrough cache. If they set FOPEN_DIRECT_IO in every FUSE_OPEN response, then they'll get no cache at all. The old vfs.fusefs.data_cache_mode sysctl is ignored for servers that use protocol 7.23 or later. However, it's retained for older servers, especially for those running in jails that lack access to the new protocol. This commit also fixes two other minor test bugs: * WriteCluster:SetUp was using an uninitialized variable. * Read.direct_io_pread wasn't verifying that the cache was actually bypassed. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349431
* fusefs: implement the "time_gran" feature.Alan Somers2019-06-265-4/+56
| | | | | | | | | | | | If a server supports a timestamp granularity other than 1ns, it can tell the client this as of protocol 7.23. The client will use that granularity when updating its cached timestamps during write. This way the timestamps won't appear to change following flush. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349403
* fusefs: delete obsolete comments in the testsAlan Somers2019-06-261-9/+0
| | | | | | | | | | | | I originally thought that the kernel would be responsible for ctime in protocol 7.23. But now I realize that's not the case. The server is responsible for ctime. The kernel only sets it when there are dirty writes cached, because that's when the server can't. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349398
* fusefs: set ctime during FUSE_SETATTR following a writeAlan Somers2019-06-261-2/+1
| | | | | | | | | | | | | | | As of r349396 the kernel will internally update the mtime and ctime of files on write. It will also flush the mtime should a SETATTR happen before the data cache gets flushed. Now it will flush the ctime too, if the server is using protocol 7.23 or higher. This is the only case in which the kernel will explicitly set a file's ctime, since neither utimensat(2) nor any other user interfaces allow it. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349397
* fusefs: automatically update mtime and ctime on writeAlan Somers2019-06-252-2/+124
| | | | | | | | | | | | | | Writing should implicitly update a file's mtime and ctime. For fuse, the server is supposed to do that. But the client needs to do it too, because the FUSE_WRITE response does not include time attributes, and it's not desirable to issue a GETATTR after every WRITE. When using the writeback cache, there's another hitch: the kernel should ignore the mtime and ctime fields in any GETATTR response for files with a dirty write cache. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349396
generated by cgit v1.3 (git 2.53.0) at 2026-08-03 10:26:41 +0000