When we receive interface information from a client to determine its
alternate IP addresses, ignore any addresses that look like loopback.
Change-Id: I245ebfc74ad1e8bd2fcd235a00f000d29229668d
Reviewed-on: http://gerrit.openafs.org/2368
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The Freelance.Local.Cell is updated by the registry monitor
thread and cm_UpdateCell should be a no-op. Make it so.
Change-Id: I2961114590af6b64b8ae06d608a97513e83aad4e
Reviewed-on: http://gerrit.openafs.org/6791
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
A successful open must have FileObject->FsContext set to a structure
with a valid/initialized FSRTL_ADVANCED_FCB_HEADER object.
Not having this breaks assumptions in the kernel.
Patchset edited by Jeffrey Altman <jaltman@your-file-system.com>
Change-Id: I70c9045bfa02c54074c015e6e871ead63efb6769
Reviewed-on: http://gerrit.openafs.org/6782
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The AFSOpenRedirector functionality must exist in the framework,
AFSRedir.sys, not the library, AFSRedirLib.sys.
Change-Id: Id688efba016d94df558b241e9bee421c86c60e27
Reviewed-on: http://gerrit.openafs.org/6781
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
If the Bug Check flag is set, the call to AFSBreakPoint() in
AFSExAllocatePoolWithTag() will trigger. There is no need for
an explicit bug check test in AFSExAllocatePoolWithTag().
If AFSExAllocatePoolWithTag() returns NULL there is no need
to ASSERT() the return value since AFSBreakPoint() would already
have been called to signal a debugger.
Change-Id: Ie8564f41f811c3afd99dc2e9c02f4aa68d63ef8e
Reviewed-on: http://gerrit.openafs.org/6780
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
This reverts commit 209df87d08.
Turning on BugCheck by default was a good idea because we needed
to track down the cause of exceptions that were otherwise being
thrown resulting in resource leaks. However, it is a bad idea
because it results in out of memory conditions throwing bug checks
that result in a BSOD.
Change-Id: If0965657957ed73b83686a9be42b0d7f89964f2f
Reviewed-on: http://gerrit.openafs.org/6779
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The current usage of make_h_tree.pl adds a build requirement of
/usr/bin/perl that we did not have prior to commit
1d6593e952. Do the same thing in a
bourne shell script instead, so we don't need perl.
Note that this is not as generalized as make_h_tree.pl, but it doesn't
need to be. Specifically, this does not strip a leading ../ from found
include directives (nothing in the tree that includes h/* files uses
this), and header filenames containing whitespace almost certainly do
not work correctly.
The h => sys mapping is also much more hardcoded, but that's all we
were using this for anyway.
Change-Id: If07888abfdb9e8ec822b33abed0bf744b7210a52
Reviewed-on: http://gerrit.openafs.org/6790
Reviewed-by: Russ Allbery <rra@stanford.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Currently we always fork a child in the salvager in order to salvage a
volume group. I believe this is in order to protect SEGV, exit(), etc
in one salvage operation from preventing salvaging anything else. When
salvaging a single volume group, though, there appears to be little
benefit.
In addition, we need to keep the VG salvaging code in the same process
as the cleanup code for single-volume salvages, so we can know which
volumes were deleted by SalvageVolumeGroup, so we know which volumes
to bring back online. So, do not fork for the singleVolumeNumber case.
Note that for DAFS, we already never fork for the entire salvage
operation when salvaging an individual volume group. So, this is
effectively a non-DAFS-only change.
Change-Id: I2b646b9ff932a673c714bc27ac32ed41cc3e22e6
Reviewed-on: http://gerrit.openafs.org/6787
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The 'fileName' field in VolumeSummary serves two apparent purposes:
- Storing the filename of the volume header file (V0XXX.vol).
- Indicating whether or not a given VolumeSummary object is
referenced by any inodes on disk. fileName is set by
AskVolumeSummary/GetVolumeSummary, and is cleared in
SalvageFileSys1 when a matching inodeSummary entry is found.
This is very confusing. The first purpose is completely unnecessary;
we can always calculate the filename from the volume id for the
volume, and we already enforce the filename to be of that specific
format. The second purpose is very unclear in the current code, and
overloads the meaning of the field.
So instead, remove fileName entirely. Code that was using it to locate
the header file are changed to use VolumeExternalName_r. Code that was
using the field to determine if the volume is "unused" is changed to
use a field just called "unused", set to 0 or 1.
Change-Id: I5e257ea633b7ae821136c88e1b2024f62125ab30
Reviewed-on: http://gerrit.openafs.org/6786
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
In MaybeZapVolume, currently we do not remove the volume header if the
given isp->volSummary->fileName is not set. This effectively means
that we only actually "zap" volumes for which we have just created the
header, or which are not referenced by any inodes.
For readonly volumes that have errors, we want to delete the volumes
instead of salvaging. Readonly volumes with valid headers will have
fileName as NULL, though (set back in SalvageFileSys1), so
MaybeZapVolume will refuse to remove them. What ends up happening is
that the headers will stay around, but since we do not finish checking
the volume, all of the inodes for the data in the volume will be
dec'd. This results in a volume whose header exists, but none of its
inodes (including special inodes) exist, so the volume will need to be
salvaged again, and during that salvage will be deleted (because there
are no inodes for the volume).
Avoid all this, and just delete volume headers for volumes that lack a
valid fileName. Instead try to avoid deleting headers with
volSummary->deleted set, just so we don't try to delete the same
headers twice.
Related issue reported by Åsa Andersson.
Change-Id: I4797d0cabe3851debdc78f4ed9ee619534397970
Reviewed-on: http://gerrit.openafs.org/6784
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, SalvageVolumeHeaderFile will set isp->volSummary->fileName
to a new string whenever the volume header needs to be created or
re-written. When control reaches back to SalvageFileSys1, this can
cause DeleteExtraVolumeHeaderFile to delete the header, since
vsp->fileName is used as a sort of indicator to see whether or not a
volume has been referenced by the inode summary.
When we create a new header, we avoid this because we allocate a new
VolumeSummary struct, which is not caught by the last
DeleteExtraVolumeHeaderFile for loop in SalvageFileSys1. However, we
do delete the header when we simply re-write a header, since we use
the existing VolumeSummary struct. Set fileName in neither, for
consistency.
Change-Id: Ibb7b5fbadb701028a6bafe01ae9f8d3265e2f443
Reviewed-on: http://gerrit.openafs.org/6783
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
afs_notify_change currently just returns "-code". This can cause a
panic if the error code is negative, since we will return a positive
error code, which may get interpreted as a valid pointer value in
higher levels.
Specifically, if we hit afs_notify_change via something like this code
path:
do_sys_open -> do_filp_open -> open_namei -> may_open -> do_truncate
-> notify_change -> afs_notify_change (via inode->i_op->setattr)
the positive error value will be interpreted by do_sys_open as a valid
'struct file' pointer, and will be dereferenced.
So pass the return value through afs_convert_code, like all of the
other vnode ops, so we ensure we return an error properly.
Change-Id: I941cc2d77d5a96cf86dfe133d30af4ccf6e9f2cb
Reviewed-on: http://gerrit.openafs.org/6776
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
afs_notify_change is almost always used solely in inode_operations
structs, and is more similar to the other per-vnode functions. Put it
with the other per-vnode functions for better organization, and so
they can use the same static functions.
Move the helper functions iattr2vattr and vattr2inode along with it.
Change-Id: I47a69fe673cfc3318ce583596ba25cbeb9cb0b96
Reviewed-on: http://gerrit.openafs.org/6775
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
if we get e.g. an idle dead error we should retry
retriable actions, namely data stores. in order
for writing files to work correctly given how
the writeback code is structured it's important that
this not interfere with analyze's shouldRetry decision
on those RPCs
Change-Id: Ie091a72b924c8414ec66c377fa13da14575a69cf
Reviewed-on: http://gerrit.openafs.org/6749
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
notify the redirector that the directory data version has
changed when a pioctl is used to create a symlink or mount point.
FIXES 130589
Change-Id: I07e1ae130b9db8d3dd68fef892c47de008be7cd4
Reviewed-on: http://gerrit.openafs.org/6747
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The AFSPerformObjectInvalidate() was obtaining exclusive
access to the Fcb ExtentsResource even though it was not
tearing down the extents list. The ExtentsResource could
be held shared instead. Doing so will avoid the following
deadlock:
Thread 1:
nt!MmPurgeSection+0x403
nt!CcPurgeCacheSection+0x100
AFSRedirLib!AFSPerformObjectInvalidate+0xd4
AFSRedirLib!AFSWorkerThread+0xa4
nt!PspSystemThreadStartup+0x2e
Thread 2:
AFSRedirLib!AFSAcquireShared+0x18
AFSRedirLib!AFSMarkDirty+0x68
AFSRedirLib!AFSNonCachedWrite+0x603
AFSRedirLib!AFSCommonWrite+0x5fa
AFSRedirLib!AFSWrite+0x20
nt!IofCallDriver+0x45
AFSRedir!AFSWrite+0x57
nt!IofCallDriver+0x45
fltMgr!FltpDispatch+0x6f
nt!IofCallDriver+0x45
AMFilter+0x2c6e
nt!IofCallDriver+0x45
PMDriver+0x112a
nt!IofCallDriver+0x45
OpLoader+0x1cd2
nt!IofCallDriver+0x45
savonaccesscontrol+0x6f15
savonaccessfilter+0x2fa0
nt!IofCallDriver+0x45
nt!IoAsynchronousPageWrite+0xd0
nt!MiMappedPageWriter+0x127
nt!PspSystemThreadStartup+0x2e
Thread 1 is attempting to perform a cache purge which cannot complete
until Thread 2 is finished but Thread 2 requires the ExtentsResource
which is held by Thread 1.
Change-Id: I4582093cf973f61cf6aff0df5e23b6711ec708b3
Reviewed-on: http://gerrit.openafs.org/6744
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Prior to 1.6.2 the file server does not report an accurate value
for the lock state. In addition, callbacks are not broken when
locks are freed due to lease expiration.
Change-Id: I5b79d1d59c2ace9834cf23dfbef33e343ce6dda0
Reviewed-on: http://gerrit.openafs.org/6741
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
locks are issued on a lease. If the lock is expired, the lock
count is zero.
Change-Id: I628dd5b8b0d38694d653d9e8e82ff60ec2e1505c
Reviewed-on: http://gerrit.openafs.org/6740
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
tid is now unused - remove it to avoid a warning.
Change-Id: If2d4fdf16415bbf19de3cd8a3e621d04d4d9b018
Reviewed-on: http://gerrit.openafs.org/6743
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Currently, h_TossStuff_r bails out and logs a message if we detect
that somebody grabbed a reference or locked the host while we tried to
h_NBLock_r. The reasoning for this is that it is not legal for anyone
to h_Hold_r a host that has HOSTDELETED set (but the error is
detectable and recoverable); callers are supposed to check for
HOSTDELETED and not hold a host in that case.
However, HOSTDELETED may not be set when h_TossStuff_r is called,
since we call it if either HOSTDELETED _or_ CLIENTDELETED are set. If
CLIENTDELETED is set and HOSTDELETED is not, it's perfectly fine (and
necessary) for callers to grab a reference to the host. So, if that's
what is going on, don't log a message, since that's normal behavior.
Check for HOSTDELETED before we h_NBLock_r, since it is technically
possible (and legal) for someone to grab a reference to the host and
somehow set HOSTDELETED while we wait for h_NBLock_r to return. Also
log the flags when we see this message.
Change-Id: Ie50a0617de094bb1c721da28f100ed4b31aa849f
Reviewed-on: http://gerrit.openafs.org/6733
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
We added this address to the host with an addInterfaceAddr_r call just
a few lines before, which adds the host to the address hash table.
Another call to h_AddHostToAddrHashTable_r is pure overhead and
confusing.
Change-Id: Ib08817274e632f67776956ede8b56eaf0dce879e
Reviewed-on: http://gerrit.openafs.org/6729
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, in h_GetHost_r, if we get a connection whose address does
not match an extant host, but the reported uuid does, we ProbeUuid the
old host. If it fails, we call MultiProbeAlternateAddress_r and set
'probefail'. Later on, if 'probefail' is set, we always add the
connection address to the host, and remove the host->host,host->port
address from the host.
However, this is not always correct. Consider the following situation.
We have an existing host that has primary address 1.1.1.1, and also
has addresses 1.1.1.2 and 1.1.1.3 on the interface list but not on the
hash table. Say that host A stops responding on 1.1.1.1, and a
connection comes in from 1.1.1.2. We ProbeUuid 1.1.1.1 and get a
failure, so we call MultiProbeAlternateAddress_r.
MultiProbeAlternateAddress_r probes via rx_Multi the addresses 1.1.1.2
and 1.1.1.3. Say that 1.1.1.3 responds first, and responds
successfully, so MultiProbeAlternateAddress_r sets 1.1.1.3 to be the
primary address for the host.
After MultiProbeAlternateAddress_r returns, 'probefail' is set. A few
lines down, we see that oldHost->host does not match haddr, and
'probefail' is set, so we add 1.1.1.2 to the interface list, and
remove 1.1.1.3, and set 1.1.1.2 to be the primary address, even though
1.1.1.3 is the address we most recently 'know' is correct.
To fix this, only set 'probefail' if MultiProbeAlternateAddress_r also
fails after the failed ProbeUuid call. Conceptually this makes sense,
since if MultiProbeAlternateAddress_r succeeds, it found an address
that responds successfully to ProbeUuid, and it sets that address to
be the primary address. Therefore, after MultiProbeAlternateAddress_r
returns success, the situation is the same as if the 'good' address
was already the primary address, and the ProbeUuid call succeeded, so
'probefail' should be cleared.
Change-Id: Id32817916a8a42db567ad099aae00745b79598c5
Reviewed-on: http://gerrit.openafs.org/6728
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The functions MultiBreakCallBackAlternateAddress_r and
MultiProbeAlternateAddress_r try to find a valid address in a host's
interface list of addrs. If they find one, they update host->host and
host->port. However, they do so just by changing those fields directly
and by calling h_DeleteHostFromAddrHashTable_r and
h_AddHostToAddrHashTable_r. This leaves the old host->host, host->port
on the interface list, and leaves it marked as 'valid'. Similarly, the
new host and port may still be marked as not 'valid'.
This can result in the host being on the addr hash table via an
address that is not on the host's interface list. After the above
situation occurs, we may call
removeInterfaceAddr_r(host, host->host, host->port);
and then update host->host and host->port, which happens in a variety
of places. Since host->host, host->port is not marked as valid in the
interface list, it is not removed from the addr hash table, but it is
removed from the interface list. Eventually, this can cause the host
to be referenced from the addr hash table even after it has been
freed.
Since this can result in hash table entries pointing to the 'wrong'
host, this can result in FileLog messages such as:
Sun Feb 5 03:16:35 2012 Removing address that does not belong to host 0xdeadbeefdead (1.2.3.4:7001).
And bogus instances of the message:
Sun Feb 5 03:16:36 2012 CB: new identity for host 0xdeadbeefdead (1.2.3.4:7001), deleting(1 baadcafe 12345678-9abc-def0-12-34-456789abcdef fedcba98-76543210f-ed-cb-a9876543210f)
To fix this, make MultiBreakCallBackAlternateAddress_r and
MultiProbeAlternateAddress_r update the address list the same way as
all of the code in host.c does; by adding the new address with
addInterfaceAddr_r, removing it with removeInterfaceAddr_r, and
updating host->host and host->port.
Change-Id: I0a95e0186c03c1831c4df86daae901bf2462da0e
Reviewed-on: http://gerrit.openafs.org/6727
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, when the fileserver gets a new connection from an address
not on the addr hash table, we allocate a new host structure and add
that host to the addr hash table. If we then find that that host's
uuid matches the uuid of an extant host, we do the following:
- probe the old host with the uuid, and MultiProbeAlternateAddress_r
if the probe fails
- mark the duplicate host as HOSTDELETED
- manipulate the interface lists
Consider, for example, that we have an extant host ('oldHost') with
address 1.2.3.4:7001, but with 5.6.7.8:7001 on its alternate interface
list. At some point, the 1.2.3.4:7001 interface goes away or becomes
unreachable. A new connection comes in from that same host on
5.6.7.8:7001.
What will happen is we create a new host for address 5.6.7.8:7001, and
then detect the uuid collision. When we try to probe the old address
of 1.2.3.4:7001, it will fail, and we will try to
MultiProbeAlternateAddress_r. MultiProbeAlternateAddress_r will
determine that the alternate address 5.6.7.8:7001 responds
successfully to the probe, and it tries to set 5.6.7.8:7001 to be the
primary address of 'oldHost', and add 'oldHost' to the addr hash table
under 5.6.7.8:7001.
But the "new" host from the incoming connection is already hashed on
the address hash table under 5.6.7.8:7001, so the
h_AddHostToAddrHashTable_r call in MultiProbeAlternateAddress_r fails.
Since we later delete the new duplicate host, this results in
5.6.7.8:7001 being the primary address for the host, but that address
is not anywhere in the address hash table.
This behavior can be seen by the following pair of FileLog messages:
Wed Feb 1 11:02:38 2012 CB: ProbeUuid for 0xdeadbeefdead (1.2.3.4:7001) failed -01
Wed Feb 1 11:02:38 2012 h_AddHostToAddrHashTable_r: refusing to hash host beefdead, baadcafe (5.6.7.8:7001) already hashed
While those message do not necessarily indicate this problem, this
problem will result in those messages.
To fix this, mark the duplicate host as HOSTDELETED before we do any
probing on 'oldHost'. This way, if MultiProbeAlternateAddress_r tries
to add 'oldHost' to the addr hash table under 5.6.7.8:7001, it will be
able to do so successfully, since the old duplicate host is deleted.
Change-Id: Id3aaab0718425492dca1deba892725160677b85f
Reviewed-on: http://gerrit.openafs.org/6726
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
If an rx call has the RX_CALL_PEER_BUSY flag set, but the call's
conn->lastBusy is not set, we can easily cause an rx caller to loop
infinitely. rx_NewCall will see that lastBusy for a call channel is
not set, and will use that call channel, but rxi_CheckBusy will note
that the call appears busy and that there are non-busy call channels
on the same conn, and so will return RX_CALL_BUSY.
This can currently happen in rxi_ResetCall, since we set
RX_CALL_PEER_BUSY on the call again if the call had that flag set when
rxi_ResetCall was called. If we are calling rxi_ResetCall with
'newcall' set, the passed in call is unrelated to the new call, since
it was obtained from the free list. Thus, the busy-ness of the call
should be ignored. Fix this by only paying attention to the incoming
RX_CALL_PEER_BUSY flag if 'newcall' is not set.
Also prevent this from happening by clearing RX_CALL_PEER_BUSY in
rx_NewCall when we select a call and clear lastBusy for that call.
Change-Id: Ic5a4709854b62d962ed91ee0103c6cbdd735d175
Reviewed-on: http://gerrit.openafs.org/6707
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
allow writing of data where it's not user data we're changing
(e.g. allow a vnode to be marked cloned in the vnode index)
Change-Id: If3338ab0474ddbfe895b705217d61c054c4cb696
Reviewed-on: http://gerrit.openafs.org/6251
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
effectively the same functionality that reclone already uses, but
for some reason we artificially limit it out of clone despite
the interface being there for it. it used to be there. put it back.
Change-Id: I22868c41f8d3b920ba61d01e5334ff2320b38376
Reviewed-on: http://gerrit.openafs.org/6250
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
remove EROFS error which is the only thing preventing a working clone
on a non-RW.
Change-Id: Ic3d4d07519188712e9a38267fc74ebd1eaef7d8a
Reviewed-on: http://gerrit.openafs.org/6249
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
If the machine has been upgraded from an AFS SMB Server to the
AFS Redirector, the registry will have leftover configuration
for the "AFS" netbios name in the Lsa BackConnectionHostNames
value and the LanmanWorkstation ReconnectableServers and
ServersWithExtendedSessTimeout values. These values are not
useful with the AFS Redirector since \\AFS is owned by afsredir.sys
and not the SMB redirector. Remove the "AFS" netbios name from
these values when afsd_service.exe has started in redirector mode.
Change-Id: If8c100d3569595645c041ac58fedb1c835f9129f
Reviewed-on: http://gerrit.openafs.org/6737
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
There were several different real and made-up hostnames and company names used
throughout our documentation examples.
The IETF has reserved "example.com" and other "example" TLDs for use in
examples (RFC 2606). Replace almost all references to ABC Corporation, DEF
Corporation, and State University, as well as "abc.com", "bigcell.com",
"def.com", "def.gov", "ghi.com", "ghi.gov", "jkl.com", "mit.edu",
"stanford.edu", "state.edu", "stateu.edu", "uncc.edu", and "xyz.com".
Standardize on "Example Corporation", "Example Network", "Example
Organization" (example.com, example.net, and example.org).
The Scout documentation in the Admin Guide contains PNG images that contain
the old cell names, so I left those references until the images can be
replaced.
Change-Id: I4e44815b2d2ffe204810b7fd850842248f67c367
Reviewed-on: http://gerrit.openafs.org/6697
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The Unix Mode bits were not being saved. This patch permits
them to be saved.
FIXES 130572
Change-Id: I6bf96c04115ee0f01e84b44b9efaacb578d95cbc
(cherry picked from commit 534d95ef90ac5e5ebf5deb227008e0b023e7ef8b)
Reviewed-on: http://gerrit.openafs.org/6734
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The DirectoryEnumEvent is not required to implement:
AFSSetEnumerationEvent
AFSClearEnumerationEvent
AFSIsEnumerationInProgress
The DirectoryEnumCount is modified by interlocked operations
and can be used as a marker for when an enumeration is in progress.
Change-Id: I414ce2bc753b0fd60a3fac51c2cf3d264a32ab05
Reviewed-on: http://gerrit.openafs.org/6725
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
AFSPrimaryVolumeWorkerThread held the VolumeCB->ObjectInfoTree.TreeLock
exclusively across calls to AFSCleanupFcb() which in turn triggers
a file extent release to the service which can in turn result in
an object invalidation. Processing the invalidation requires shared
access to VolumeCB->ObjectInfoTree.TreeLock which results in a deadlock.
This patch alters the processing of AFSPrimaryVolumeWorkerThread
so that the VolumeCB->ObjectInfoTree.TreeLock is not held across
the AFSCleanupFcb() calls.
FIXES 130431
Change-Id: I3726df02ab47d2dcc83a32c75957a5dafcfbf20e
Reviewed-on: http://gerrit.openafs.org/6724
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The daemon thread's loading and unloading of afsdhook.dll every
second prevents the disk drive from sleeping and forces a search
of the PATH. Make the periodic reloading configurable and
disable it by default.
Change-Id: I7e1a5b2bc7e1c4d4ea39fc30cf34c1195a326ed2
Reviewed-on: http://gerrit.openafs.org/6715
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
If acquisition of the Global\AFS_KTC_Mutex fails, return a
different error code from a pioctl failure since the pioctl
was never issued.
Change-Id: I001227f87e97a06bf419c68d6579843e4f93f032
Reviewed-on: http://gerrit.openafs.org/6710
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Cache the value of GetComputerNameW() to avoid repeated calls
for each and every redirector ioctl request.
Change-Id: I4476db982897a631510eba7d859385268b16ce34
Reviewed-on: http://gerrit.openafs.org/6708
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Currently, the openafs-client RPM init script ignores any error
reported by rmmod. If 'umount /afs' succeeds but rmmod does not, the
client may panic the machine if the client is started again (from e.g.
running the 'restart' init script method), since afsd will try to
initialize AFS with a libafs that has been shut down.
So, do not ignore errors from 'rmmod', and instead fail the 'stop'
method from the init script if we get an error.
Change-Id: Id4a07703fb4df69ad3a6a3569c91e48f73a0d309
Reviewed-on: http://gerrit.openafs.org/6709
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Change the default cell from openafs.org to grand.central.org
since there is no openafs.org cell. All openafs software is
distributed from the grand.central.org cell.
Change-Id: I21ea2c5a9b55fbe3bb4ea19ae34ecf0e5a38084f
Reviewed-on: http://gerrit.openafs.org/6699
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Master does not track a particular version number.
For Windows builds on master, reset the version to
0.0.0 so that the builds are not confused with the actual
1.5.7600.
Change-Id: I3c84bb117418284de0d65e2a4069b88908b91659
Reviewed-on: http://gerrit.openafs.org/6698
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
