Bug 218795 - FileObject.getChildren(true) should handle recursive symlinks gracefully
FileObject.getChildren(true) should handle recursive symlinks gracefully
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
7.3
PC Linux
: P2 with 1 vote (vote)
: 7.4
Assigned To: Jaroslav Havlin
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-21 15:13 UTC by Svata Dedic
Modified: 2013-08-22 04:26 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Test to verify the system works (4.24 KB, patch)
2012-10-22 12:36 UTC, Jaroslav Tulach
Details | Diff
Patch with two possible implementations (20.85 KB, patch)
2013-06-27 15:20 UTC, Jaroslav Havlin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Svata Dedic 2012-09-21 15:13:31 UTC
It seems that the call will recurse indefinitely in a structure where a symlink loops back to parent directory. I suggest that a child FO whose canonical path is a prefix of its parent is excluded from the enumeration (= ignore upwards symlinks).

see e.g. report http://statistics.netbeans.org/exceptions/exception.do?id=610277, the binary scan seem to be stuck in home directory.
Comment 1 Jaroslav Tulach 2012-10-22 12:36:27 UTC
Created attachment 126323 [details]
Test to verify the system works

I've started with a test, and made it fail. Then I wanted to prevent that behavior, however I realized there is no check in masterfs API for symlinks. The bug 208392 does all the detection in parsing.api.

The only thing that comes to my mind is to move the code from parsing.api to masterfs. I leave it up to you guys whether you want to prepare such patch. If so, I happily use the symlink detection inside of FolderObj.getChildren(true).
Comment 2 Jaroslav Tulach 2012-10-22 12:37:54 UTC
Parsing API needs to donate the symlink detection code to openide.filesystems(?) for this request to be implementable.
Comment 3 Jaroslav Tulach 2012-10-31 16:00:52 UTC
Tomáši, let me know where the symlink detection code is, please.
Comment 4 Tomas Zezula 2012-10-31 21:16:58 UTC
Looking at the log http://statistics.netbeans.org/exceptions/exception.do?id=610277 there is no FO.getChildren(). Wrong link or did I overlooked it?
Comment 5 Tomas Zezula 2012-10-31 21:18:02 UTC
I will firstly look  where the getChildren() is called and why.
Comment 6 Tomas Zezula 2013-01-08 18:30:37 UTC
From the attached log I cannot find the call of getChildren(true).
Also it's not so easy an API to correctly detect links (including Win NTFS junctions) should be added into FileUtil.
Comment 7 Tomas Zezula 2013-05-30 14:02:59 UTC
I've found several life locks caused by this issue in recent issues evaluations, back to P2.
Comment 8 Jaroslav Havlin 2013-06-27 15:20:41 UTC
Created attachment 136416 [details]
Patch with two possible implementations

I’ve checked the implementation in parsing API, and I copied the algorithm to FileUtil.isUnderRecursiveSymlink(FileObject).

I’ve also tried to implement a method that detects symlinks directly, FileUtil.isRecursiveSymlink(FileObject).

I guess the latter one is more user-friently, as the symbolic link can be detected even if the file path doesn’t contain two equal elements. The performance seems to be similar.

Can you please check the two methods and let me know if you find any problems in them (mainly performance), and which of them should be in the final patch for API review?

Thank you in advance.


Notes:
 - Tests are in module masterfs, because it’s easier to use 
   FileUtil.toFileObject(getWorkDir()) there. If you know about some better 
   place, please let me know.
 - I only changed FileUtil.getChildren(boolean), I’m not sure whether
   non-recursive methods should take care of recursive symlinks.
 - Result of FileUtil.isUnderRecursiveSymlink depends on the path to link.
   For example, let's have two symlinks in directory /a, named /a/b and /a/a, 
   both pointing to /a.
   Method isUnderRecursiveSymlink() for the first one returns false, but for 
   the second one true. It's because it contains two elements with the same 
   name. Expected is false for both, because /a/a is not under a symlink.
Comment 9 Jaroslav Havlin 2013-08-19 09:56:33 UTC
http://hg.netbeans.org/core-main/rev/51103e05a74f
Fixing only FileObject.getChildren(true), no API has been changed, FileUtil.isRecursiveSymlink is package private.

A more general API for accessing info about symbolic links should be introduced later.
Comment 10 Quality Engineering 2013-08-22 04:26:46 UTC
Integrated into 'main-silver', will be available in build *201308212300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/51103e05a74f
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #218795: FileObject.getChildren(true) should handle recursive symlinks gracefully


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo