Opened 19 years ago
Closed 19 years ago
Last modified 19 years ago
#2211 closed defect (fixed)
SVN can't delete relative symlinks
Reported by: | mythtv-dev (at) dwilga-linux1.amherst.edu | Owned by: | cpinkham |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | low | Keywords: | |
Cc: | Ticket locked: | no |
Description
Myth is failing to resolve relative symlinks.
In my setup, I have my recordings stored in /media/record, and an NFS-mounted folder at /media/nfs to move them to when the main HD becomes to full. I create symlinks like:
something.nuv -> ../nfs/something.nuv
Here's the output of 'mythbackend -v file':
2006-08-11 08:17:22.991 About to unlink/delete file: '/media/record/3332_20060518165900.nuv' 2006-08-11 08:17:22.999 Error deleting '../nfs/3332_20060518165900.nuv' could not open
eno: No such file or directory (2)
2006-08-11 08:17:23.006 Delete Error '/media/record/3332_20060518165900.nuv' -> '../nfs/3332_20060518165900.nuv'
eno: No such file or directory (2)
2006-08-11 08:17:23.015 Error deleting file: /media/record/3332_20060518165900.nuv. Keeping metadata in database.
This suggests that Myth is trying to delete the file using ".." in the path, which is incorrect because mythbackend was not started in /media/record. To confirm this theory, I stopped mythbackend, cd'd to /media/record, restarted it, and then deleted the recording. It worked.
Change History (3)
comment:1 Changed 19 years ago by
Milestone: | → 0.21 |
---|---|
Status: | new → assigned |
Summary: | SVN won't delete symlinks → SVN can't delete relative symlinks |
comment:2 Changed 19 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 19 years ago by
At some point this may be changed to follow only symlinks that point below the Recording Directory, but this has not been implemented right now as part of this fix.
When this is fixed it will only be fixed for relative links in subdirs, not for ../ type links pointing to other directory trees. This will probably be done at the same time as #2228 is put into SVN. For more info on why, read #2228.