View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000823 | LDMud 3.5 | Portability | public | 2013-08-03 03:22 | 2014-02-23 21:23 |
| Reporter | abathur | Assigned To | zesstra | ||
| Priority | low | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000823: save_object fails without hard linking support | ||||
| Description | save_object will throw 'Operation not permitted' errors if attempted on a system without hardlink support (which can happen for Linux virtualbox VMs which share the mudlib folder, at least). There used to be support in object.c for using rename instead of link for certain OSes, though instead of an OS-specific check it would be nice if there was just a config-time check for hard-link support. I'd implement this and send up a patch if I knew how to do the config/detection side of things, as the actual code change in object.c is pretty trivial. | ||||
| Additional Information | https://github.com/ldmud/ldmud/blob/master/src/object.c#L6863 is the line where the link() function is. If you check the version history you can see where it previously used unlink(f) and rename() to accomplish this for dos and other systems. | ||||
| Tags | No tags attached. | ||||
|
|
I may be wrong, but AFAIR is link() specified by POSIX 2001 and we made the decision to rely on POSIX conformity for 3.5.x. The reason was to NOT have the code littered with exceptions for little-used special cases. Another thing: I am quite sure, this has nothing to do with the VM, but with the filesystem being mounted by something, which does not support hard links. (BTW: if you use SMB, you may try to use CIFS instead which purportedly supports hard links... |
|
|
That's correct, and I think that's sufficient reasoning. I did get a chance to test out the CIFS share today. It was glacially slow, and while it didn't fail with the operation-not-permitted error, it did fail with the text-file-busy error (which suggests it would probably work, albeit very slowly, if the close(f); appeared before the link() call. There are two other workarounds; one is to just work internal to the VM, but setting up a gui and an editing environment takes a lot more time, and requires pushing any code changes to the remote repository if I need to teardown the VM. The other is to create a copy of the mudlib local to the VM, and re-copy it when changes are made. This is probably the most workable of the workflows, but there's still some unnecessary friction. I mostly mean to suggest that there's some advantage to having an LDMud implementation which is trivial to get running in a development-friendly VM regardless of host OS. Would it perhaps be more acceptable to try rename only if link fails, and maintain a single execution path? |
|
|
I am sorry for the blunt words, but: I personally would prefer not to do workarounds for broken systems. rename() has a race condition you can't really avoid and which can lead to files being unintentionally overwritten, so I prefer not to use it. You could use your private patch if you really need it. BTW: I do not think it is a good idea (in general) to share the same mudlib with several instances of the driver running at the same time. I changed severity and priority because this is a rare issue which has several rather easy workarounds (and it is not really a bug because we require POSIX compliance). |
|
|
I closing this and suggest to use either a local patch or (better) a filesystem with hardlink support (I still believe, it is not an original problem of a virtual machine.) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-08-03 03:22 | abathur | New Issue | |
| 2013-08-06 21:54 | zesstra | Note Added: 0002191 | |
| 2013-08-10 02:24 | abathur | Note Added: 0002193 | |
| 2013-08-18 16:51 | zesstra | Note Added: 0002195 | |
| 2013-08-18 16:51 | zesstra | Priority | normal => low |
| 2013-08-18 16:51 | zesstra | Severity | block => feature |
| 2013-08-18 16:51 | zesstra | Status | new => acknowledged |
| 2014-02-23 21:23 | zesstra | Note Added: 0002228 | |
| 2014-02-23 21:23 | zesstra | Status | acknowledged => closed |
| 2014-02-23 21:23 | zesstra | Assigned To | => zesstra |
| 2014-02-23 21:23 | zesstra | Resolution | open => won't fix |
