mavftp: Define how virtual drives work

[hamishwillee]

In mavlink/mavlink#2409 (comment) we discussed supporting LOG upload using MAVFTP and a virtual drive. This has a number of benefits - with a virtual drive the upload can be flight-stack agnostic, MAVFTP is quite efficient, and also allows for checking CRCs etc, so you can know what you have already downloaded.

To do this we need to formalise how MAVFTP virtual drives work, and also agree the names for virtual drives.

@julianoes @peterbarker I have done so here. But since ArduPilot already uses this for parameters (right) it should be checked to make sure it is compatible. Questions inline

[hamishwillee]

Is all of this correct? Specifically, this was indicating that you specify the brackets for the componennt, while I think that those were probably supposed to be BNF indicating "optional".

The implication though is that there are three slashes to indicate a camera if you don't have a component ID or drive: mftp:///camera.xml

Can you clarify what works now?

[hamishwillee]

So my understanding is that we're just prefixing the virtual drive as the first part of the path. The recieving system has to do the mapping. If a system returns a full path it would also have to include the prefix.

[peterbarker]

[11:02 AM]Peter Barker: Yeah, I gave this a little thought.
[11:03 AM]Peter Barker: Virtual drives actually opens a bit of a can of worms.  Just because you know where a directory full of files exist doesn't mean that it's helpful.  Are all files in the directory log files (LASTLOG.txt isn't for ArduPilot!).  Are you going to assume .BIN (probably not true for PX4, they have sdlog or something?).

[julianoes]

@peterbarker what's wrong with QGC just displaying the files as it finds them and the user to download what they need? It doesn't have to be machine readable but if you know to look in @log folder, that's a start.

[hamishwillee]

@peterbarker what's wrong with QGC just displaying the files as it finds them and the user to download what they need? It doesn't have to be machine readable but if you know to look in @log folder, that's a start.

I agree. If a flight stack wants to clutter up their logs directory with some other data, that's a problem, but it is their own problem.
Of course after uploading a GCS still needs to understand the log format, but that is true with the old method too.

Is the rest of it sane?

[julianoes]

Regarding the specific LOG_FILES messages: for PX4 it was/is actually a pain because QGC would have to come up with its own name and date/version scheme for the filenames separate from what it is on the SD card, which means it's not trivial to compare later which log files have already been downloaded and which ones haven't.

[peterbarker]

On Wed, 11 Feb 2026, Hamish Willee wrote: [5368500?s=20&v=4] hamishwillee left a comment (mavlink/mavlink-devguide#668) @peterbarker what's wrong with QGC just displaying the files as it finds them and the user to download what they need? It doesn't have to be machine readable but if you know to look in @log folder, that's a start. I agree. If a flight stack wants to clutter up their logs directory with some other data, that's a problem, but it is their own problem. Of course after uploading a GCS still needs to understand the log format, but that is true with the old method too.

No, it's a problem for things that want to automate things when unexpected stuff pops up.

Is the rest of it sane?

Not necessarily. You're assuming the files exist in a directory. They don't on many ArduPilot boards. Logs stored in *actual* dataflash don't necessarily. We can determine a list of logs for the existing mavlink interface, but trying to treat them like files is *not* going to work well (e.g. you can't delete a single file) This may have changed with the advent of littlefs in ArduPilot - but there I don't know what capabilities are available and what aren't. What I'm saying is that there's currently an abstraction which let's the autopilot present the data in a consistent format which you are intending to remove. All that being said, tridge has expressed interest in having a file in ArduPilot's @sys which points to where the log files are or something to allow something to FTP the files down from a discovered location. What you're suggesting here is a standardised version of that.

[julianoes]

No, it's a problem for things that want to automate things when unexpected
stuff pops up.

Sure, a tool that downloads flight logs just has to know what the filename/folder logic looks like for the particular flight stack. However, a more generic ground station like QGC can just present the folders and users will figure out which file they need, I'd say.

present the data in a consistent format which you are intending to remove.

We're not removing or breaking anything. We're just encouraging/recommending to use FTP in the future. If you stick with the LOG_FILES API, that's fine in my eyes. Once or if you figure out how to present it as files, then you can swap, or offer both.

All that being said, tridge has expressed interest in having a file in
ArduPilot's @sys which points to where the log files are ...

Yes, I was thinking that too. I feel like AP has already a lot of the plumbing around making things files.

[hamishwillee]

Thanks @julianoes @peterbarker

1. Just for me https://ardupilot.org/dev/docs/filesystems.html#flash-based-virtual-file-systems

2. FWIW The changes here are mostly about defining how MAVFTP should represent a virtual or aliased file system. While LOG Is the example, for me the changes are really about offering pathway to any such virtual drive. It's a first step to stating that you might present @param as a drive for any flight stack. Next we could argue the format :-).

   • FMI Is @param represented as a file or a drive when it gets loaded by ArduPilot

3. I mostly agree with @julianoes ^^^ in mavftp: Define how virtual drives work #668 (comment)

   • IMO the 99% case would not be able to work with this approach if we can make it work reasonably with all the log use cases.
   • I think the automated tool argument is somewhat weak.
     A tool that wants to know about files already needs to know about the flight stack-specific log formats. It does need to be more robust against unwanted files. That's not an unreasonable expectation - a tool that doesn't check what file types it is loading is already broken.
   • While this can co-exist quite happily with LOG_FILES I would much rather we were able to work out mechanisms to use it as a replacement.

4. ... You're assuming the files exist in a directory. They don't on many ArduPilot boards. Logs stored in actual dataflash don't necessarily. We can determine a list of logs for the existing mavlink interface, but trying to treat them like files is not going to work well (e.g. you can't delete a single file).

   Yes I am, but is this really any different from the log API? In that you can't delete an individual file, but instead you must erase all logs using https://mavlink.io/en/messages/common.html#LOG_ERASE

   Using MAVFTP you would NAK an attempt to delete an individual file with FileProtected. However you would allow the deletion of a directory: https://mavlink.io/en/services/ftp.html#remove-directory

   Because this is standardized, the GCS can present a UI that duplicates the LOG behaviour in all respects other than the directory might contain non-log files, and in theory you might be able to delete a file.

   Without wanting to derail the discussion, worst case we could add a mechanism to allow file/drive properties to be read.

5. All that being said, tridge has expressed interest in having a file in ArduPilot's @sys which points to where the log files are or something to allow something to FTP the files down from a discovered location. What
   you're suggesting here is a standardised version of that.

   Yes. I also wouldn't be adverse to having some kind of approach where we have a pointer to logs that can be downloaded by MAVFTP. Though I'd use component metadata because it is a standardized and generic discovery method.

   But if we want to expose @sys, again, these updates are what would be a good way to do it.

[peterbarker]

I'd also point out that while ArduPilot doesn't support COMPONENT_METADATA (except in a branch) it would appear the correct way to point to where the logs for the vehicle are stored. For vehicles which are streaming directly into "the cloud" (several ArduPilot partners do this) the place to find the logs isn't on the vehicle. So discovering where you can download logs directly via mavftp may not be the be-all-and-end-all the process. Frankly I think we might just ignore that and go with the virtual filesystem thing as a viable option for now - it wouldn't preclude pointing there in the component metadata later.

[hamishwillee]

I'd also point out that while ArduPilot doesn't support COMPONENT_METADATA (except in a branch) it would appear the correct way to point to where the logs for the vehicle are stored. For vehicles which are streaming directly into "the cloud" (several ArduPilot partners do this) the place to find the logs isn't on the vehicle. So discovering where you can download logs directly via mavftp may not be the be-all-and-end-all the process. Frankly I think we might just ignore that and go with the virtual filesystem thing as a viable option for now - it wouldn't preclude pointing there in the component metadata later.

@peterbarker Sorry, I was still editing #668 (comment) - it has new comments.

I added a similar comment re component metadata and I hadn't even thought of the cloud use case. Could not agree more that it provides a more flexible way to point to logs, but does not preclude using a virtual FS.
Of course you could define @sys virtual drive with the compenent metadata root file in MAVFTP too - then you wouldn't even have to query for it via the COMPONENT metadata interface. Forget I ever said any of this, I love that interface.

Can you look at the other stuff I suggested to address the data flash issues.

Essentially I think the issues you have raised are all mitigated - can you accept the idea in principle? Then I can update to capture that stuff and re-review and take to our various communities to discuss.