How does WIMLIB treat a file inside a capture folder when some of the hard links in that file point to an outside folder?
Are those links still stored inside the WIM at capture time?
At extraction time, are those external hard links created outside of the target extraction folder - in a relative path to the original capture folder, or to an absolute path as was found at capture time?
Hard Links Outside of Capture Folder
-
synchronicity
- Site Admin
- Posts: 501
- Joined: Sun Aug 02, 2015 10:31 pm
Re: Hard Links Outside of Capture Folder
A hard link doesn't "point" to another file name, but rather directly to the file itself. So this question doesn't make a lot of sense. There's no "outside folder" that the links point into.
Re: Hard Links Outside of Capture Folder
Please allow me to explain.
WIMLIB captures a given file system folder, right?
So what happens when a file inside that capture folder has hard links to files *outside* of that capture folder (where outside is defined as a folder wholly external to the capture folder, and specifically is not a subfolder of the capture folder)?
WIMLIB always handles hard links auto-magically - where it stores them during capture, and creates them as necessary during extraction/application, right? So there's no multiple copies of a file, but hard links created to that file - exactly as it was during capture time.
But what is WIMLIB coded to do when hard links cross capture folder boundaries in the manner above described?
Does WIMLIB then again store hard links to paths external to the capture folder, and does WIMLIB create those hard links again at extraction/application time of the created WIM?
If so, does WIMLIB relativize those folder paths to the root of the capture folder, or does it store them as absolute paths to the root of the capture device?
Of course, one could also come up with a "security" angle on the above question - if paths are relativized (and even maybe when they are stored as absolutes), this means some files may "escape" a given extraction/application folder (and end up [over]writing files outside of the specified extraction/application target folder), but that is not my actual concern here.
My goal is to be able to re-create a given system layout, even when I am forced to break the capture into multiple WIM files(say, capturing each root file system folder individually into multiple WIMs, instead of capturing the entire root file system atomically into a single WIM).
Hope that helps?
WIMLIB captures a given file system folder, right?
So what happens when a file inside that capture folder has hard links to files *outside* of that capture folder (where outside is defined as a folder wholly external to the capture folder, and specifically is not a subfolder of the capture folder)?
WIMLIB always handles hard links auto-magically - where it stores them during capture, and creates them as necessary during extraction/application, right? So there's no multiple copies of a file, but hard links created to that file - exactly as it was during capture time.
But what is WIMLIB coded to do when hard links cross capture folder boundaries in the manner above described?
Does WIMLIB then again store hard links to paths external to the capture folder, and does WIMLIB create those hard links again at extraction/application time of the created WIM?
If so, does WIMLIB relativize those folder paths to the root of the capture folder, or does it store them as absolute paths to the root of the capture device?
Of course, one could also come up with a "security" angle on the above question - if paths are relativized (and even maybe when they are stored as absolutes), this means some files may "escape" a given extraction/application folder (and end up [over]writing files outside of the specified extraction/application target folder), but that is not my actual concern here.
My goal is to be able to re-create a given system layout, even when I am forced to break the capture into multiple WIM files(say, capturing each root file system folder individually into multiple WIMs, instead of capturing the entire root file system atomically into a single WIM).
Hope that helps?