# Need udev rule to create symlink [SOLVED]

## gentsquash

[edit]I've simplified my question to just the 4th post.[/edit]

(WAS: udev was working in /dev/tts/, now fails intermittently)

For many months now I have been successfully syncing my Palm

Pilot, having  RC_DEVICE_TARBALL="yes" in /etc/conf.d/rc and a symlink

```
pilot -> tts/USB0
```

in /dev/.  When I pressed the hotsync button, two devices were

created in /dev/tts/: USB0 and USB1; the former turned out to be

the Palm. (Perhaps USB1 is the Palm-cradle?)

I updated to udev-056 and have had sometimes-work/sometime-fail subsequently.  

Searching the forums lead to my trying this rule

```
SYSFS{product}="Palm Handheld", KERNEL="ttyUSB*", NAME="tts/USB%n", 

 SYMLINK="pilot%e", GROUP="tty", MODE="0666"        (all on one line)
```

in 10-udev.jk-local.rules (in /etc/udev/rules.d/).  This usually

works when I first log-in, but later in the day, instead of

USB0/1 being created, I see USB2 & USB3.  Sometimes I see all

four USB0/1/2/3 created.  The /dev/pilot symlink sometimes points

to the new USB2 or USB3.  While the Palm is still trying to hotsync, I

have manually deleted the symlink, and re-made it to each of USB0/1/2/3, to no avail.

I've tried many combinations of: Deleting the devices, Deleting

the symlink; Having run, or not, udevstart; With

```
RC_DEVICE_TARBALL="yes"
```

or ="no" (and rebooting).  Nothing has worked except when the

rule has created exactly USB0/1 and made the symlink

pilot->USB0.  Once it stops working (e.g it starts creating a

USB2, even if no USB0/1 exist), then --so far-- only rebooting

has fixed the problem.

My 50-udev.rules is the one that came with udev; it has rule

```
KERNEL="ttyUSB[0-9]*",   NAME="tts/USB%n", GROUP="tty", MODE="0600"
```

and I haven't touched it.  I've had this failure with both udev-056 and udev-058.

I seek any reliable solution.   AFAIK, I use no other devices

that create or need USBx in /dev/tts/.  (I do have a usb mouse,

and it works fine.)  So far, I have read 10 threads on udev+PDA and have

tried 6 rules in 10-udev.jk-local.rules.

----------

## overkll

Hello Professor

You might want to try the unstable versions of udev.  I think 0.63 was just released.  It may or may not help out.

Just a thought.

----------

## gentsquash

Right you are, and I appreciate the suggestion.  udev-063 is

marked "unstable" --I'd sure prefer to stay on the stable side

for something as fundamental as device-allocation.

I need to correct my previous posting: When the syncing fails,

the only reliable solution I've found is

 reinstalling udev, followed by rebooting.

Once my udev starts allocating a USB2, it seems to store, somewhere,

its state.  Hence forth, even if I delete all devices USBx and

all symlinks to such, nonetheless udev starts by creating USB2

and USB3.  Rebooting doesn't fix this.

Does anyone know  I can reset udev?; cmd udevstart doesn't do it.

 Is its state stored in /dev/.udevdb/ ?  Can I safely delete this dir, or the files within it?

Most importantly, 

can anyone suggest a better udev rule that will

reliable create a /dev/pilot symlink to the PDA?

----------

## gentsquash

I am currently trying udev-063 and am looking for a suggestion to

replace the rule 

```
SYSFS{product}="Palm Handheld", KERNEL="ttyUSB*",

  NAME="tts/USB%n", SYMLINK="pilot%e", GROUP="tty", MODE="0666"
```

that I have /etc/udev/rules.d/10-udev.local.rules.  Upon

pressing <hotsync>, I see devices USB0 and USB1 (in /dev/tts/)

and sometimes I see symlinks

```
pilot  -> tts/USB0

pilot1 -> tts/USB1
```

but sometimes the symlinks are reversed (pilot  -> tts/USB1).

Can some kind folk show me a rule that always creates

pilot  -> tts/USB0? (It is irrelevant if the other symlink is made.)

----------

## vuud

 *gentsquash wrote:*   

> I am currently trying udev-063 and am looking for a suggestion to
> 
> replace the rule 
> 
> ```
> ...

 

We seem to be having the same problem at the same time - of course mine never worked right so far.  But I cannot also resolve the moving USB# target problem.

----------

## Headrush

I don't think you can force a USB device to use a specific USB number.

The purpose of SYMLINKS in the udev rules is to work around this. Normally you should access the device with the SYMLINK you create.

As you have found out, depending on the discover order of USB devices, your device could be any /dev/tts/USB#.

If you correctly start referencing your SYLINK, it will always point to the correct device node, whether it be USB0, USB1, ... USB99

Can you post output of:

```
lsusb -v
```

With this I think I can make a rule for you.

----------

## vuud

 *Headrush wrote:*   

> I don't think you can force a USB device to use a specific USB number.
> 
> The purpose of SYMLINKS in the udev rules is to work around this. Normally you should access the device with the SYMLINK you create.
> 
> As you have found out, depending on the discover order of USB devices, your device could be any /dev/tts/USB#.
> ...

 

Any help would be great... I've tried many combinations based on the serial number or the product name... the problem is that it keeps getting a new USB number each time.  Not even changing the order.  If I boot up and hit hotsync, i get USB0 and USB1.  The next time I hit hotsync (without unplugging or adding anything) I get USB2 and USB3...  Sometimes its the same until I try to actually connect it with kpilot and it opens the device and says to hit hotsync I get a new number.

I'd be eternally greatful for a solution!

```
Bus 002 Device 069: ID 0830:0061 Palm, Inc. 

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               1.00

  bDeviceClass            0 (Defined at Interface level)

  bDeviceSubClass         0 

  bDeviceProtocol         0 

  bMaxPacketSize0        16

  idVendor           0x0830 Palm, Inc.

  idProduct          0x0061 

  bcdDevice            1.00

  iManufacturer           1 palmOne, Inc.

  iProduct                2 palmOne Handheld

  iSerial                 5 504E35424D314C3556315648

  bNumConfigurations      1

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           46

    bNumInterfaces          1

    bConfigurationValue     1

    iConfiguration          0

    bmAttributes         0xc0

      Self Powered

    MaxPower                2mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           4

      bInterfaceClass       255 Vendor Specific Class

      bInterfaceSubClass      0 

      bInterfaceProtocol      0 

      iInterface              0 

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x81  EP 1 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval              10

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x02  EP 2 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x86  EP 6 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x07  EP 7 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

  Language IDs: (length=4)

     0409 English(US)
```

----------

## Headrush

Sorry I need the lsusb -v after you hit the hotsync button.

You can't stop it from changing the USB#, that behaviour is normal. You need to make a constant SYMLINK that never changes.Last edited by Headrush on Mon Jul 18, 2005 11:49 pm; edited 1 time in total

----------

## vuud

 *Headrush wrote:*   

> Sorry I need the lspci -v after you hit the hotsync button.
> 
> You can't stop it from changing the USB#, that behaviour is normal. You need to make a constant SYMLINK that never changes.

 

That was the entry for the palm from after I hit hotsync from lsusb...  I cut it out of the whole thing

I had it at one point making me a solitary pilot symlink based on udev rules, but it did not work at all

The USB creates two... one is basically nothing, the other should be the palm

Oh wait - the first time you said lsusb...  not lspci

Here is the lspci -v, but I think you were really looking for the lsusb...

```
0000:00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 11)

        Flags: bus master, fast devsel, latency 0

        Memory at f0000000 (32-bit, prefetchable)

        Capabilities: [e4] #09 [a104]

        Capabilities: [a0] AGP version 2.0

0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 11) (prog-if 00 [Normal decode])

        Flags: bus master, 66Mhz, fast devsel, latency 64

        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32

        I/O behind bridge: 00002000-00002fff

        Memory behind bridge: fc200000-fc4fffff

        Prefetchable memory behind bridge: f4000000-fc1fffff

        Expansion ROM at 00002000 [disabled] [size=4K]

0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 05) (prog-if 00 [Normal decode])

        Flags: bus master, fast devsel, latency 0

        Bus: primary=00, secondary=02, subordinate=03, sec-latency=64

        I/O behind bridge: 00001000-00001fff

        Memory behind bridge: fc800000-fd5fffff

        Prefetchable memory behind bridge: ebe00000-efdfffff

0000:00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 05)

        Flags: bus master, medium devsel, latency 0

0000:00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 05) (prog-if 80 [Master])

        Subsystem: Compaq Computer Corporation: Unknown device 2411

        Flags: bus master, medium devsel, latency 0

        I/O ports at 3480 [size=16]

0000:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 05) (prog-if 00 [UHCI])

        Subsystem: Compaq Computer Corporation: Unknown device 2411

        Flags: bus master, medium devsel, latency 0, IRQ 19

        I/O ports at 3440 [size=32]

0000:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 05) (prog-if 00 [UHCI])

        Subsystem: Compaq Computer Corporation: Unknown device 2411

        Flags: bus master, medium devsel, latency 0, IRQ 23

        I/O ports at 3460 [size=32]

0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 05)

        Subsystem: Compaq Computer Corporation: Unknown device 008a

        Flags: bus master, medium devsel, latency 0, IRQ 17

        I/O ports at 3000

        I/O ports at 3400 [size=64]

0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) (prog-if 00 [VGA])

        Subsystem: ATI Technologies Inc: Unknown device 0000

        Flags: bus master, stepping, 66Mhz, medium devsel, latency 66, IRQ 5

        Memory at f4000000 (32-bit, prefetchable) [disabled]

        I/O ports at 2000 [disabled] [size=256]

        Memory at fc400000 (32-bit, non-prefetchable) [disabled] [size=64K]

        Capabilities: [58] AGP version 2.0

        Capabilities: [50] Power Management version 2

0000:01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000] (Secondary) (rev 01)

        Subsystem: ATI Technologies Inc: Unknown device 0001

        Flags: bus master, stepping, 66Mhz, medium devsel, latency 66

        Memory at f8000000 (32-bit, prefetchable)

        Memory at fc410000 (32-bit, non-prefetchable) [size=64K]

        Capabilities: [50] Power Management version 2

0000:02:08.0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM Ethernet Controller (rev 03)

        Subsystem: Compaq Computer Corporation EtherExpress PRO/100 VM

        Flags: bus master, medium devsel, latency 66, IRQ 20

        Memory at fd300000 (32-bit, non-prefetchable)

        I/O ports at 1400 [size=64]

        Capabilities: [dc] Power Management version 2

0000:02:09.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 15) (prog-if 00 [Normal decode])

        Flags: bus master, medium devsel, latency 66

        Bus: primary=02, secondary=03, subordinate=03, sec-latency=66

        Memory behind bridge: fc800000-fd2fffff

        Prefetchable memory behind bridge: 00000000ec000000-00000000efd00000

        Capabilities: [80] Power Management version 2

        Capabilities: [90] #06 [0000]

        Capabilities: [a0] Vital Product Data

0000:02:0a.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)

        Subsystem: Adaptec 29160N Ultra160 SCSI Controller

        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 21

        BIST result: 00

        I/O ports at 1000 [disabled]

        Memory at fd301000 (64-bit, non-prefetchable) [size=4K]

        Capabilities: [dc] Power Management version 2

0000:02:0d.0 FireWire (IEEE 1394): Agere Systems (former Lucent Microelectronics) FW323 (rev 04) (prog-if 10 [OHCI])

        Subsystem: Indigita Corporation FireWire Host Bus Adapter

        Flags: bus master, medium devsel, latency 64, IRQ 18

        Memory at fd302000 (32-bit, non-prefetchable)

        Capabilities: [44] Power Management version 2

0000:03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85) (prog-if 00 [VGA])

        Subsystem: Matrox Graphics, Inc.: Unknown device 0d43

        Flags: bus master, medium devsel, latency 64, IRQ 5

        Memory at ec000000 (32-bit, prefetchable)

        Memory at fd200000 (32-bit, non-prefetchable) [size=16K]

        Memory at fc800000 (32-bit, non-prefetchable) [size=8M]

        Capabilities: [dc] Power Management version 2

        Capabilities: [f0] AGP version 2.0

```

----------

## Headrush

Can you post your current rules file? /etc/udev/rules.d/10-udev.rules

When you hit the hotsync button and it creates two /dev nodes, do either of them work. 

(Doesn't matter whether USB0 or USB1, etc)

Try this rule:

```
BUS="usb", KERNEL="ttyUSB[13579]", NAME="tts/USB%n", SYMLINK="pilot", MODE="0666"
```

Mode="0666" isn't the best permissions mode, you may want to change that and add a group with appropriate permissions.

----------

## vuud

 *Headrush wrote:*   

> Can you post your current rules file? /etc/udev/rules.d/10-udev.rules
> 
> When you hit the hotsync button and it creates two /dev nodes, do either of them work. 
> 
> (Doesn't matter whether USB0 or USB1, etc)
> ...

 

Damn, that worked.  I can access it via kpilot now... while there seems to be much wrong with the connection itself...  I can work out the usb group stuff... Thanks very very much.

One other question, while I am heaping praise on you for your solution... 

When I connect the palm and set it to drive mode, which makes it a USB storage device...  I get this in my dmesg

```

usb 2-2: new full speed USB device using uhci_hcd and address 25

ubb: device 25 capacity nsec 330624 bsize 512

ubb: device 25 capacity nsec 330624 bsize 512

 /dev/ub/b: p1

```

But I do not get a /dev/ub directory...  I have no idea how to approach it not that I am udev'd...

And my lsusb for the palm device changes slightly (idProduct)

Any thoughts on this would be great also.  The stinking palm just keeps locking up anyway

```
Bus 002 Device 025: ID 0830:00dd Palm, Inc. 

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               1.00

  bDeviceClass            0 (Defined at Interface level)

  bDeviceSubClass         0 

  bDeviceProtocol         0 

  bMaxPacketSize0        16

  idVendor           0x0830 Palm, Inc.

  idProduct          0x00dd 

  bcdDevice            1.00

  iManufacturer           1 palmOne, Inc.

  iProduct                2 palmOne Handheld

  iSerial                 5 504E35424D314C3556315648

  bNumConfigurations      1

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           32

    bNumInterfaces          1

    bConfigurationValue     1

    iConfiguration          0

    bmAttributes         0xc0

      Self Powered

    MaxPower              100mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           2

      bInterfaceClass         8 Mass Storage

      bInterfaceSubClass      6 SCSI

      bInterfaceProtocol     80 Bulk (Zip)

      iInterface              0 

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x86  EP 6 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x07  EP 7 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

  Language IDs: (length=4)

     0409 English(US)

```

----------

## Headrush

 *vuud wrote:*   

> 
> 
> ```
> 
> usb 2-2: new full speed USB device using uhci_hcd and address 25
> ...

 

What about /dev/ubb?

Can you post 

```
ls -l /dev
```

 *vuud wrote:*   

> And my lsusb for the palm device changes slightly (idProduct)

 

This is normal.

What kernel are you running?

```
uname -a
```

----------

## gentsquash

(O.P. here) Thank you Headrush for your advice, which I slightly

modified to 

```
SYSFS{product}="Palm Handheld", BUS="usb", KERNEL="ttyUSB[02468]", 

  NAME="%k", SYMLINK="pilot", GROUP="tty", MODE="0660"
```

So far it has worked thrice; I haven't tried rebooting yet.  Hitting

<hotsync> (either the hardware-button on the cradle, or the

software-button on the Palm) creates

```
/dev/tts/USB1

/dev/ttyUSB0

pilot -> ttyUSB0   (in /dev/)
```

and my Palm does indeed sync under kpilot. (I presume that USB1

is the cradle, but who knows?) 

I'll keep testing this to see if, OMSystem, it is reliable.  Is

there any reason for me to modify the rule so that the device

representing the Palm is in /dev/tts/?

Thanks Headrush for your speedy response.  (And thank you

vuud for your postings, keeping the thread going while I was

taking my kids swimming... --how did you know??)

----------

## Headrush

 *gentsquash wrote:*   

> I'll keep testing this to see if, OMSystem, it is reliable.  Is
> 
> there any reason for me to modify the rule so that the device
> 
> representing the Palm is in /dev/tts/?

 

Probably not, unless there is some program that is hardcoded to look there only.

In general, when I make my own udev rules, I leave the original kernel device node name and then create SYMLINKs. I use the SYMLINKS when setting up all apps, but the original nodes still exist if I happen to use an old program that isn't so smart  :Cool: 

The subdirectories in /dev/ are purely cosmetic and created by the /etc/udev/rules.d/50-udev.rules file.

----------

## vuud

 *Headrush wrote:*   

>  *vuud wrote:*   
> 
> ```
> 
> usb 2-2: new full speed USB device using uhci_hcd and address 25
> ...

 

Wow, you are da MAN!!!

My Kernel is 2.6.10-gentoo-r2 #5 SMP 

I do have the /dev/ubb which I tried to mount but I get the wrong fs, bad option, bad superblock error...  I was guessing it was VFAT, but I really am not sure what it is... more research I suppose

Do you still need the ls -l for dev?  Its long...

----------

## Headrush

 *vuud wrote:*   

> I do have the /dev/ubb which I tried to mount but I get the wrong fs, bad option, bad superblock error...  I was guessing it was VFAT, but I really am not sure what it is... more research I suppose
> 
> Do you still need the ls -l for dev?  Its long...

 

No. If you have /dev/ubb, then do you have additional /dev/ubb# nodes?

If yes, those are the ones to mount.

----------

## vuud

 *Headrush wrote:*   

>  *vuud wrote:*   I do have the /dev/ubb which I tried to mount but I get the wrong fs, bad option, bad superblock error...  I was guessing it was VFAT, but I really am not sure what it is... more research I suppose
> 
> Do you still need the ls -l for dev?  Its long... 
> 
> No. If you have /dev/ubb, then do you have additional /dev/ubb# nodes?
> ...

 

Wow, yes... ubb1 worked and mounted fine as VFAT

I wish I ran into you much earlier in the day, it was killing me trying to work this out.  I cannot express how grateful I am for the help, nor the great sense of relief I feel now that I got this far.  I just can't put it into words... I am amazed that it works - and thats all due to you.  Thanks very very much!

----------

## Headrush

 *vuud wrote:*   

>  *Headrush wrote:*    *vuud wrote:*   I do have the /dev/ubb which I tried to mount but I get the wrong fs, bad option, bad superblock error...  I was guessing it was VFAT, but I really am not sure what it is... more research I suppose
> 
> Do you still need the ls -l for dev?  Its long... 
> 
> No. If you have /dev/ubb, then do you have additional /dev/ubb# nodes?
> ...

 

Glad its working. You might find that /dev/ubb# changes and is not constant. This is normal for hotplugable USB devices. To help with that you may want set up a a custom udev rule that makes a symbolic link to the correct device node.

eg. Instead of /dev/ubb1 or /dev/ubc1 you would access the constant /dev/usbdrive1

There are several threads on this already, just trying searching on udev AND rules.

----------

## vuud

 *Headrush wrote:*   

>  *vuud wrote:*    *Headrush wrote:*    *vuud wrote:*   I do have the /dev/ubb which I tried to mount but I get the wrong fs, bad option, bad superblock error...  I was guessing it was VFAT, but I really am not sure what it is... more research I suppose
> 
> Do you still need the ls -l for dev?  Its long... 
> 
> No. If you have /dev/ubb, then do you have additional /dev/ubb# nodes?
> ...

 

Thanks much!  I discovered kpilot will only sync so much before crashing - otherwise I think I am doing well.  I will check the links about udev and rules...  Once again, I really appreciate the help (it was a time of great desperation)

----------

## mjbjr

And you don't even really need a symlink...

this works fine for me

BUS="usb", SYSFS{product}="Palm Handheld", SYSFS{serial}="PalmSNxxxxxxxxxxxx", NAME="treo", GROUP="uucp"

sub your own serial number, of course.

ls -l /dev/treo

crw-rw----  1 root  uucp  188,  1 Jul 19 13:22 treo

# ls -l /dev/tts/U*

crw-------  1 root tty 188, 0 Jul 19 13:51 /dev/tts/USB0

crw-------  1 root tty 188, 1 Jul 19 13:51 /dev/tts/USB1

both are created on cradle sync button push

while I do have some rules with 'SYMLINK', now that I think about it, I'm not sure why you'd ever use them....

notice that they both (treo and USB1) have the same major/minor numbers.  Possbily, having multiple different processes accessing

two separate but dentical devices can cause collision conflicts that  are handled better as a collisions (via links)

at the same device.

hmmm... in testing for this reply, I just had a situation where /dev/treo was created, but /dev/tts/USB* was not created

and it worked!  Go figure.     :Wink: 

.

.

----------

## Headrush

SYMLINKs are not a requirement, but personally I like to keep the original KERNEL name and then choose the names I prefer as symlinks, including overriding the entries in 50-udev.rules for all the devices I have. Just personal preference. 

The problem with Palms is that it seems so many of the models are different and detection order is different. Some work differently depending on whether being accessed as mass storage device or after hitting hot-sync button. A little tweaking is needed depending on your model.

 *mjbjr wrote:*   

> while I do have some rules with 'SYMLINK', now that I think about it, I'm not sure why you'd ever use them.... 

 

Because some programs default to or are hardcoded to look for devices at specific spots.

For example, my dvd burner used to be my only optical drive. So CD programs look for /dev/cdrom, dvd playing programs look for /dev/dvd, and burning program looks for /dev/dvdr. Sure I can edit the programs and change the locations, but easier to just have multiple symlinks to the same node.

----------

## gentsquash

(O.P. here)  After a reboot, the syncing still works.

Thanks Headrush for your sage advice.

----------

## Headrush

 *gentsquash wrote:*   

> (O.P. here)  After a reboot, the syncing still works.
> 
> Thanks Headrush for your sage advice.

 

Your welcome, glad I could help.

If your USB devices stays constant, you probably won't see any differences.

You're more likely to see a problem when you add addition USB devices that have storage support.

----------

## Headrush

 *mjbjr wrote:*   

> And you don't even really need a symlink...
> 
> this works fine for me
> 
> BUS="usb", SYSFS{product}="Palm Handheld", SYSFS{serial}="PalmSNxxxxxxxxxxxx", NAME="treo", GROUP="uucp"
> ...

 

My guess is that with that udev rule, only treo is created and the USBtty nodes are "leftover" from previous rules.

----------

