This includes removing the cred files used to accress P2P peers.
Note that the P2P auth token, which is used to auth incoming
connections, is stored in a cred file, but not one named with the uuid
of a remote, so it will not be deleted by this. Which is as intended,
see commit ddad858a81
For fsck, there is also a fsck state file. When annex.dbdir is set,
the fsck db is stored in that path, but the fsck state file remains
under .git/annex. So, disableremote separately deletes the fsck state
file.
Also, delete the fsck results log file.
Note that this could cause another process, that is running and getting
content from the remote, to start failing, since the content identifiers
get removed.
Much of the time, this removal will be pointless because the reposizes
database is updated from the git-annex branch, and so long as the
git-annex branch contains infortmation about the uuid, a later update
of the database will just add back the removed uuid to it.
But, for a private remote, this does clean out its uuid from the
reposizes database. Note that Command.DisableRemote was changed to clean
the private journal before removing from the database.
Note that the removal is done in a single transaction, which is why
it's ok to update the LiveSizeChanges, SizeChanges, and RecentChanges
tables. Other updates that involve those tables are also done
transactionally, and so a concurrent writer will leave things in a
consistent state.
Of course, another process that is running concurrently and updating the
database could lose the race, and so put back the uuid into the
database. I don't think that can be avoided.
There are per-uuid fsck and export databases, so disableremote can
remove them only when the remote being disabled is the only remote for
its uuid.
Lock files are also attempted to be removed, since they also contain the
uuid. This may fail on windows since the removal happens while the lock
file is still open? I have not checked. But it seems important to remove
the lock while it's locked, to avoid any race with some other process
that might open the database. If such a process got its own open lock
deleted out from underneath it, that could cause a problem if there is a
third process that also writes to the same database in a race.
Note that, in the case where disableremote is running, and at the same
time another process starts up and wants to write to these databases,
it's possible that it will re-create the database after disableremote
has deleted it. I don't think this can be avoided, and it's seems
very unlikely.
The P2P auth token is used to authenticate incoming connections
from a peer, and just because a p2p remote is being deleted does not
mean that the user intends to prevent that peer from continuing to use
the repository.
Was able to reuse the code that drops dead remotes from the git-annex
branch to filter the remote uuid out of the private journal log files.
This makes me very happy about the design of that code.
Also there is a special case for --sameas to remove the config uuid from
remote.log.
