View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003391 | Far Manager | Copy/Move | public | 2017-01-28 10:54 | 2020-03-19 14:27 |
Reporter | pepak | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | unable to reproduce | ||
Platform | x64 | OS | Windows | OS Version | 7 |
Product Version | 3.0 | ||||
Summary | 0003391: Move: Inherit Access Rights not inheriting correctly | ||||
Description | When performing a Move (F6) with access rights set to "Inherit", the access rights get copied (well, not exactly, see below) rather than inherited. | ||||
Steps To Reproduce | Source files: "." -> Everyone:RX (inherited from the parent directory, propagates to all sub-objects) ".\A.TXT" -> Everyone:RX (inherited from .) ".\B" -> Everyone:RX (inherited from .) ".\B\B.TXT" -> Everyone:RX (inherited from .\B) Destination directory: "T:\DEST" -> Everyone:F (explicit, propagates to all sub-objects) Move ".\A.TXT" to "T:\DEST": - Expected result: "T:\DEST\A.TXT" -> Everyone:F (inherited from T:\DEST) - Actual result: "T:\DEST\A.TXT" -> Everyone:RX (inherited from ??? - surprisingly, there really is the "inherit" flag on the file!!) Move ".\B" to "T:\DEST": - Expected result: "T:\DEST\B\B.TXT" -> Everyone:F (inherited from T:\DEST\B, which itself inherits from T:\DEST) - Actual result: "T:\DEST\B" -> Everyone:RX (inherited from ???) - Actual result: "T:\DEST\B\B.TXT" -> Everyone:RX (inherited presumably from T:\DEST\B, but it could be inherited from ??? too) | ||||
Additional Information | Copy (F5) seems to work correctly with access rights set to "Inherit". I suspect that in both cases, the setting is actually ignored and "Default" is used for access rights. At least, that's what the observed behavior indicates. The bug is present since at least build 4797, possibly longer. | ||||
Tags | No tags attached. | ||||
Build | 0 | ||||
duplicate of | 0000987 | closed | При move не обрабатывается случай inherit в копировании прав доступа. |
|
Interestingly enough, it seems to have started to work with a new instance of the FAR's process. So it would seem the error isn't simply "Inherit doesn't work", but instead "Something can make Inherit to be skipped during Copy/Move". |
|
I presume you moved files to another volume in the first case, but not in the second? It's known "feature" and default OS behaviour, see https://blogs.msdn.microsoft.com/oldnewthing/20060824-16 |
|
No. All the data were located on the T: drive. |
|
Is this still relevant? |
|
Not sure. Apparently the bug does not manifest all the time so there is no easy way to verify. I don't recall seeing anything that might fix it, so I suspect the bug is still there, but if I can't reproduce it reliably, then there probably isn't much point keeping the report around. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-01-28 10:54 | pepak | New Issue | |
2017-01-28 16:55 | pepak | Note Added: 0015199 | |
2017-01-28 20:13 | DrKnS | Relationship added | duplicate of 0000987 |
2017-01-28 20:16 | DrKnS | Note Added: 0015200 | |
2017-01-28 20:18 | pepak | Note Added: 0015201 | |
2020-03-19 08:51 | DrKnS | Note Added: 0016748 | |
2020-03-19 09:08 | pepak | Note Added: 0016749 | |
2020-03-19 14:27 | DrKnS | Status | new => closed |
2020-03-19 14:27 | DrKnS | Resolution | open => unable to reproduce |
2020-03-19 14:27 | DrKnS | Build | => 0 |