add rr commands to manage recordings

heycam commented 9 years ago

Sometimes I lose track of which recordings I've made and which I want to keep. It would be nice if rr had command line commands to manage recordings by name so you can do things like:

$ rr list
firefox-0
firefox-1 (latest)
firefox-4
$ rr mv firefox-0 firefox-bug123-repro
$ rr rm firefox-1  # maybe rr rm latest, too
$ rr replay firefox-bug123-repro

I can of course do this by moving directories around in ~/.rr. But it would be nice just like it's nice with Mercurial queue management.

rocallahan commented 9 years ago

Sounds like a great project for a new contributor :-)

zmaril commented 9 years ago

I'm interested in doing this and have some time to work on it. Is there a particular set of commands that folks are interested in using? Off the top of my head I can think of ls, mv, rm and cp.

rocallahan commented 9 years ago

The main thing that's nontrivial for me at the moment is examining a set of traces to find the one I want. So I'd really like a command that lists traces in order of last modification and gives me basic information about them: the command line of the tracee, the start time, and the duration (computable by subtracting the last modification time of a trace file from the creation time of the trace directory). Maybe also the size of the trace in human-readable units.

I think it would be nice to have rr ls by analogy with ls and provide compatible options. In particular by default it would sort alphabetically and display just the trace name, like ls, but it would also support -t to sort from newest to oldest, -r to reverse the sort order, and -l to display the data I mentioned above.

rr mv to rename a trace to a reasonable name would be good. Accepting latest and latest-trace as aliases for the latest trace would make it easy to rename the trace you just created: rr mv latest found-bug-2019.

I don't think rr cp would be very useful since traces are immutable.

rr rm is probably worth having too.

One other thing that is almost related is that sometimes rr crashes or gets killed, leaving behind an unusable trace. Also, sometimes rr updates mean you can't use old traces anymore. It might be a good idea to have some kind of rr cleanup command that deletes traces that are unusable for whatever reason. This might require changing TraceWriter::close() so that it marks traces that have been properly closed. Maybe we should delay writing the version file until that point. This should probably be a different issue...

zmaril commented 8 years ago

I've gotten a rough pass of ls working locally. There doesn't seem to be a way to get creation time for files on linux nor can I find any mention of the creation time in the TraceReader code. Did you have something else in mind or did you want to have the last time the file was changed or was modified serve as a proxy for creation time?

rocallahan commented 8 years ago

There doesn't seem to be a way to get creation time for files on linux

st_ctim in struct stat as produced by stat, fstat etc.

rocallahan commented 8 years ago

Er, I guess that's not the creation time, is it?

rocallahan commented 8 years ago

But I think st_ctim of the version file should be good enough.

zmaril commented 8 years ago

Cool, thanks for the guidance. Next time there is a trace format version bump, it might make sense to roll into the trace files the creation time somehow.

Should have a working ls very soon.

rocallahan commented 8 years ago

You're welcome to bump the trace format yourself. However, I think making a commitment that the ctime of the version file is the creation time of the trace would be fine and a little simpler than encoding the creation time somewhere.

vinhill commented 1 year ago

Is this issue still relevant? I would be interested in taking this.

If so, a couple of things:

remove and move might be better names to prevent confusion with recording a trace of rm or mv system calls. This might lead to confusion if someone switches back to a version without rr rm and then unknowingly invokes the rm syscall.
How should I remove a trace folder? It seems rr is supporting c++11 builds, so there is no std::filesystem. I could use nftw and remove?
I would like to have rr remove only delete a folder if it is actually a trace or a --force option is used. What could be used as a check? Maybe looking if a version or incomplete file exists?

rocallahan commented 1 year ago

I think we can depend on C++14 now. I'll make that change in CMakeList.

I'm not really worried about someone doing rr rm trace-name and deleting a file called trace-name because they used an old version of rr. Seems like a really unlikely combo of events.

Checking for version or incomplete sounds good.

yuyichao commented 1 year ago

Re rm, I’ve wasted a lot of time since rr ls is a special command rather than a record of the ls program so I do think the confusion that may come from conflicting with command line tool name is real.

rocallahan commented 1 year ago

Why are you typing rr ls a lot?

yuyichao commented 1 year ago

It was mainly to test if rr is working, though there was a few cases where I genially traced ls. ls being the simple command of choice mostly out of habit.

Now I assume no one uses rm for this sort of testing so this should be less of an issue. However, the point was mainly that when not paying too much attention to the output one can misunderstood what the command have done and arrive at the wrong conclusion. (I've tried replaying after what I've thought was a successful recording of ls and getting very confused for a long time....)

rocallahan commented 1 year ago

heh, I've done that too, but I don't think rm is going to be a problem there.

Really rr ... is a footgun and everyone should just use rr record .... Probably can't change that now though.

rr-debugger / rr

add rr commands to manage recordings #1415