cdrom_id does not handle certain USB sticks with fake CD rom devices on them
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 16.7k
- Forks
- 4.7k
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 140
Description
There are some USB sticks that present themselves as two devices - a regular USB flash drive and a CD drive. This is done so that the data provided from the fake CD drive cannot be modified without using special tools. This is similar to the method used on U3 drives, except that the data on the fake CD is useful.
The fake CD drive on the USB stick I have is handled by cdrom_id in a way that prevents downstream components from automatically mounting the data. There are two problems:
1/ The fake drive does not have a current profile, so cdrom_id assumes that there is no media, even though there is other code to determine whether media is present.
2/ cdrom_id does not look for track information in the last eight bytes of the TOC and thus does not realize that there is a data track on the fake device.
Because of these problems, cdrom_id does not determine that there is data available on the fake drive and thus does not trigger the udev rule that sets up the by-uuid and by-label aliases for disks. These aliases are used in other code (such as in XFCE) for displaying and automounting and thus the drive is not visible on the XFCE desktop and not considered for automounting in XFCE.
The following patch fixes both these problems. I have not submitted it as a patch yet, because I don't have access to information on the TOC layout for CDs and I don't know whether the second part of the patch would introduce any new problems. I have been running the patched cdrom_id on my laptop without any problems.
Can anyone tell me whether the second part of the patch would break anything?
--- ./src/udev/cdrom_id/cdrom_id.c 2015-02-02 17:00:07.251045223 -0800
+++ /home/pfps/cdrom_id.c 2015-10-27 14:30:22.977943769 -0700
@@ -555,7 +555,8 @@
feature_profile_media (udev, cur_profile);
ret = 0; /* we have media */
} else {
- log_debug("no current profile, assuming no media");
+ log_debug("no current profile, media as per detected already");
+ ret = ( cd_media == 0 ) ;
}
len = features[0] << 24 | features[1] << 16 | features[2] << 8 | features[3];
@@ -809,7 +810,7 @@
/* Take care to not iterate beyond the last valid track as specified in
* the TOC, but also avoid going beyond the TOC length, just in case
* the last track number is invalidly large */
- for (p = toc+4, i = 4; i < len-8 && num_tracks > 0; i += 8, p += 8, --num_tracks) {
+ for (p = toc+4, i = 4; i <= len-8 && num_tracks > 0; i += 8, p += 8, --num_tracks) {
unsigned int block;
unsigned int is_data_track;
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/udev/cdrom_id/cdrom_id.c, focusing on the current-profile media decision and the TOC track loop around the lines shown in the patch. Check the relevant CD TOC layout and existing media-detection behavior, then validate that fake CD devices expose data and receive the expected by-uuid and by-label aliases without affecting ordinary discs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100