1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
Spent yesterday and today making the WebApp handle adding removable drives.
While it needs more testing, I think that it's now possible to use the WebApp
for a complete sneakernet usage scenario.
* Start up the webapp, let it make a local repo.
* Add some files, by clicking to open the file manager, and dragging them in.
* Plug in a drive, and tell the webapp to add it.
* Wait while files sync..
* Take the drive to another computer, and repeat the process there.
No command-line needed, and files will automatically be synced between
two or more computers using the drive.
Sneakernet is only one usage scenario for the git-annex assistant, but I'm
really happy to have one scenario 100% working!
Indeed, since the assistant and webapp can now actually do something
useful, I'll probably be merging them into `master` soon.
Details follow..
---
So, yesterday's part of this was building the configuration page to add
a removable drive. That needs to be as simple as possible, and it currently
consists of a list of things git-annex thinks might be mount points of
removable drives, along with how much free space they have. Pick a drive,
click the pretty button, and away it goes..
(I decided to make the page so simple it doesn't even ask where you want
to put the directory on the removable drive. It always puts it in
a "annex" directory. I might add an expert screen later, but experts can
always set this up themselves at the command line too.)
I also fought with Yesod and Bootstrap rather a lot to make the form look good.
Didn't entirely succeed, and had to file a bug on Yesod about its handling of
check boxes. (Bootstrap also has a bug, IMHO; its drop down lists are not
always sized wide enough for their contents.)
Ideally this configuration page would listen for mount events, and refresh
its list. I may add that eventually; I didn't have a handy channel it
could use to do that, so defferred it. Another idea is to have the mount
event listener detect removable drives that don't have an annex on them yet,
and pop up an alert with a link to this configuration page.
----
Making the form led to a somewhat interesting problem: How to tell if a mounted
filesystem is a removable drive, or some random thing like `/proc` or
a fuse filesystem. My answer, besides checking that the user can
write to it, was various heuristics, which seem to work ok, at least here..
[[!format haskell """
sane Mntent { mnt_dir = dir, mnt_fsname = dev }
{- We want real disks like /dev/foo, not
- dummy mount points like proc or tmpfs or
- gvfs-fuse-daemon. -}
| not ('/' `elem` dev) = False
{- Just in case: These mount points are surely not
- removable disks. -}
| dir == "/" = False
| dir == "/tmp" = False
| dir == "/run/shm" = False
| dir == "/run/lock" = False
"""]]
----
Today I did all the gritty coding to make it create a git repository on the
removable drive, and tell the Annex monad about it, and ensure it gets synced.
As part of that, it detects when the removable drive's filesystem doesn't
support symlinks, and makes a bare repository in that case. Another expert
level config option that's left out for now is to always make a bare
repository, or even to make a directory special remote rather than a git
repository at all. (But directory special remotes cannot support the
sneakernet use case by themselves...)
----
Another somewhat interesting problem was what to call the git remotes
that it sets up on the removable drive and the local repository.
Again this could have an expert-level configuration, but the defaults
I chose are to use the hostname as the remote name on the removable drive,
and to use the basename of the mount point of the removable drive as the
remote name in the local annex.
----
Originally, I had thought of this as cloning the repository to the drive.
But, partly due to luck, I started out just doing a `git init` to make
the repository (I had a function lying around to do that..).
And as I worked on it some more, I realized this is not as simple as a
clone. It's a bi-directional sync/merge, and indeed the removable drive may
have all the data already in it, and the local repository have just been
created. Handling all the edge cases of that (like, the local repository
may not have a "master" branch yet..) was fun!
|
