Project

General

Profile

Bug #13268

Part fails to load when next folder is read-olny

Added by WildLynx almost 8 years ago. Updated over 6 years ago.

Status:
Updated
Severity:
Normal
Assignee:
-
Category:
Application
Target version:
-
Start date:
11/19/2016
% Done:

10%

Version:
1.2.1
Platform:
Linux
Expansion:
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

Situation:
There is a mod (or even stock) folder with "Parts" folder.
There is "SomePartKind" folder in the "Parts" folder.
There are many "PartName" folders in the "SomePartKind" folder.
One of the "PartName" folders is set to ORX-GRX-ORX access mode, eg set to be read-only.

Effect: Parts from previous "PartName" FAIL TO LOAD! Not from folder, that is RO, but folder, that is previous to it.

History

#1 Updated by WildLynx almost 8 years ago

correction: URX-GRX-ORX

#2 Updated by WildLynx almost 8 years ago

Problem lingers, even wih attributes reverted to ARWX
Cleared Module manager cache - restored part.
Module Manager issue or stock issue?

#3 Updated by JPLRepo almost 8 years ago

  • Status changed from New to Needs Clarification

Is this a modded install?
Can you please reproduce the problem in a stock install without any mods and please provide a log file.
Details of how to do this is within the wiki page.
http://bugs.kerbalspaceprogram.com/projects/ksp/wiki
Thanks

#4 Updated by Hexicube almost 8 years ago

  • Status changed from Needs Clarification to Updated
  • % Done changed from 0 to 10

Issue occurs on Windows 7 with a fresh 1.2.2 installation, setting the entire Aero folder to read-only causes all wing parts to be missing.

Reverting it fixes the issue, parts being missing after reverting is caused by ModuleManager caching.

Logs contain "access denied" errors. Relevant section of logs: http://pastebin.com/qWB81twY

Files are being opened with "File.Open(path, mode)" inside the PartReader class, which uses read/write.
They should instead be using "File.OpenRead(path)", as no writing should occur.

#5 Updated by Ruedii almost 7 years ago

I think Hexicube has the right lead on this.

It seems that Unity faults on file open of a read-only file being opened with read-write access, instead of on writing it.

It is an issue upstream with Unity, but there is a clear workaround. One could theoretically also fix this with a fault-catch shim on "File.Open" that retries with "File.OpenRead" and then installs fault stubs where the write routine hooks for the filehandle object would be. so it faults if the program tries to write to the file. It should also log the action.

#6 Updated by Squelch over 6 years ago

  • Severity changed from Critical to Normal

Also available in: Atom PDF