Commits
- Commit:
5f362b7f054ee9e876d7b8c208fcc09b2235091f
- From:
- Omar Polo <op@omarpolo.com>
- Date:
typo spotted by cage, thanks!
- Commit:
c0ae57b900c0dda41d12793b7a0480159f2946ca
- From:
- Omar Polo <op@omarpolo.com>
- Date:
initialize evbuffer only for dirs
- Commit:
baa405044968a73fd6a257a3504efe7dc5fe7443
- From:
- Omar Polo <op@omarpolo.com>
- Date:
first half of the tread implementation done, no new tests yet
- Commit:
d4e438158258d53a0d22189b432537b22300dd2e
- From:
- Omar Polo <op@omarpolo.com>
- Date:
allow opening directories (for reading only)
- Commit:
99a435901454cc6ca529a783486c83ffddadb110
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fix walk fid check: look at fd not iomode to see if it was opened
- Commit:
87a818e80dd7b59d2ee3f9b1cdffc82d7c5c1b4c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
ensure we don't call openat(2) with "" as path
- Commit:
cf758c3329364c1516e2b78c573d6901843bc670
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fix Tattach handling
The previous implementation assumed that you can't attach more than
once. This is clearly wrong, Tattach and Twalk are the two ways to
obtain new fids.
This drops the error on subsequential attach and making the test
"multiple attach" passes.
- Commit:
3242c0bccce6e6d431c59b04e2cd955e732fa074
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't let nwqid become negative
at the start of the loop nwqid is 0, so if the first component can't be
opened nwqid becomes -1 and since it's not 0, we end up calling np_walk
with -1 as length. This in turns converts it back to uint16_t and we
generate an invalid packet.
The solution is to not decrement nwqid at all, it fixes all the current
tests case and is the correct behaviour that the rest of the code
expects.
- Commit:
054cd6b98fbb367f781b25084661076f5c1fe4b1
- From:
- Omar Polo <op@omarpolo.com>
- Date:
Twalk: validate path component
disallow empty path, the dot or components which contains the path
separator ('/'). The current implementation transforms these into a
"can't open" type of failure, I'm unsure if we want to turn these into
hard Rerror.
- Commit:
021481cadee5324ef838e632a87746cdabffd5e3
- From:
- Omar Polo <op@omarpolo.com>
- Date:
Topen implemented
Implement Topen plus some basic testing. ORCLOSE (remove file when the
fid is clunked) is mapped to O_CLOEXEC and tried to be honoured on
fid_free.
"vanilla" 9P2000 uses reads on directories to list the entries while
9P2000.L (and .U too possibly) introduces an explicit Treaddir. I'm
planning to support 9P2000-style read-on-dir but not yet.
- Commit:
5b704257daf17ddb642c3e353095663903c3247e
- From:
- Omar Polo <op@omarpolo.com>
- Date:
initialize to -1 fid' fd
- Commit:
29f1f5824909cc91325fd45105a82d1006f5e176
- From:
- Omar Polo <op@omarpolo.com>
- Date:
update qid and fid structs + docs
I've finally made up my mind regarding the qid and fid handling. fids
are fine as they currently are, I've just added some comments to don't
forget the meaning of the iomode and fd fields. The values KFIO_W/R are
new and will be soon used by the (soon to be added) Topen call.
qids keep the current semantics, but loose some fields that I've added
when I wasn't sure yet. To reiterate: a qid is a directory file
descriptor plus an optional path. If path is empty, the qid refers to
the directory, otherwise to that file in the current directory, c.f.
openat(3).
This makes implementing Topen easier: for instance, if fid1 and fid2 are
backed by the same qid, a Topen on fid1 doesn't need to alter fid1->qid,
and so fid2 is still fine. The reference counting on qids ensures that
we end up closing all the directories fd.
- Commit:
47c9b8b8b3a15c444f6621e2680181eadc8db366
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't allow duplicating a fid already opened for I/O
if a fid was opened for i/o can't be used for twalk
- Commit:
f987557cb3636bcd8ea1881625e724e77963d7db
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fmt
- Commit:
deb971f5fc2a6781df9930c143939763736b4ae6
- From:
- Omar Polo <op@omarpolo.com>
- Date:
bit of refactoring
amongst other things, walk now correctly uses fds for each step, so
we're not limited by PATH_MAX for the whole walk, but only for the
single path component.