1

The freedesktop.org media type database shared-mime-info has a filename pattern *,v associated with MIME type text/plain, and I can't figure out why - if only because ,v and *,v are basically useless as search terms!

The 2008 commit that added the pattern doesn’t explain it, though the test case does point to a bug on RedHat’s Bugzilla. There, someone had “RCS files” with filenames ending in ,v, and the bug was that they were being recognised as audio files. Without further context, I can only guess that “RCS files” refers to Revision Control System, rather than radar cross-section data or Autodesk ReCap scan files…

Why did this one user’s weird experience lead to a change in shared-mime-info for everyone? Was it a widespread problem, perhaps because RCS was known to generate files with that ending? Why was adding it to shared-mime-info an appropriate response† to the bug, rather than (say) finding out why these random files were being treated as audio?


† I say “response”, not “fix”, because it’s not clear to me that it did fix the user’s problem. The bug was closed because it ceased to occur in later versions of the software, which isn’t explicitly credited to the change in shared-mime-info.

2 Answers 2

1

RCS indeed creates files with the ,v suffix:

$ mkdir RCS
$ echo hello > hello.txt
$ ci hello.txt 
RCS/hello.txt,v  <--  hello.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test file
>> 
initial revision: 1.1
done
$ ls RCS
hello.txt,v

and they don't look exactly like the original file, so it may indeed be prudent to recognize them as something different.

$ cat RCS/hello.txt,v 
head    1.1;
access;
symbols;
locks; strict;
comment @# @;


1.1
date    2021.08.28.14.44.57;    author ilkkachu; state Exp;
branches;
next    ;


desc
@test file
@


1.1
log
@Initial revision
@
text
@hello
@

It also seems to be able to process at least some binary data, though does that in a line-based manner.

Why they would be recognized as audio files in particular, that I don't know.

1

There's enough information in the question for you to answer it yourself. The '*,v' is present to prevent audio-files which were checked into RCS from being interpreted as audio-files (because the file-formats differ, and would produce an error if one attempted to play them).

An RCS file can contain binary data, because it treats that as just another "string". The manual page mentions this without providing much detail:

Strings are enclosed by @. If a string contains a @, it must be doubled; otherwise, strings can contain arbitrary binary data.

There are several audio/video formats which can be distinguished by a program (such as file) which inspects the contents of the file. However, MIME is oriented to identifying files by their name (in particular their "suffix"), and some systems will attempt to automatically infer the MIME type using only the filename. That's inherently error-prone, and the '*,v' is a workaround to accommodate the implementation.

5
  • Two points. One, the bug reporter said the files in question were not audio files. The example file (and I think from context all of the files) had the extension .ftn,v, and .ftn is apparently an extension for Fortran source files. And two, I’m not asking “what’s the benefit of this?”, and I’ll edit the question to try and clarify that. Commented Aug 28, 2021 at 11:00
  • OP said this "the bug was that they were being recognised as audio files." which does not agree with your comment. Commented Aug 28, 2021 at 13:20
  • I am the OP. ;-) The bug is that they were recognised as audio files, even though they weren’t audio files. From the bug report: “…a bunch of RCS files… other various kinds of data file (there's no single audio file on the disk)” (by which I think they mean “not a single audio file”). Commented Aug 28, 2021 at 13:37
  • sure: but the question did not add that "even though" clause, and RCS files can contain binary content such as audio files. (fwiw, I do this with png files). Commented Aug 28, 2021 at 14:37
  • Ah, I’m sorry it wasn’t clearer. I guess I thought the “even though” was implied: if “doing X” is a bug, then it implies that the software is doing X even though it shouldn’t. Commented Aug 28, 2021 at 15:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .