Accessing File within Symbolic Link Directory Issue

General
1

Hello all -

I need to access a file from a directory that is a folderitem of a symbolic link, but Xojo 2014r1.1 on Linux Mint 16 Petra (64 bit) and OS X (10.9.3) both fail with reporting the file does not exist.

I’ve been staring at the debugger all day on both Linux and OS X and I’m out of ideas. First thought is that it doesn’t seem like the folderitem that gets assigned to the symlink for the ‘TestDir’ is not resolving correctly.

Here’s the sample code from the test app:

[code]dim mAppFolder as FolderItem = GetFolderItem("")

// The files below are created in the ‘CreateSymLinks[TARGET]’ build step:

dim mSymLinkDir as FolderItem = mAppFolder.Child(“TestDir-SymLink”)
dim mSymlinkFileInDir as FolderItem = mSymLinkDir.Child(“TestFileA-Symlink”)

if ( mSymlinkFileInDir.Exists ) then

SymFileInDirTestLabel.Text = "mSymlinkFileInDir exists."

else

SymFileInDirTestLabel.Text = "mSymlinkFileInDir does NOT exist."

end if
[/code]

I’ve double checked that the paths are correct in the terminal. In fact I’m creating the real directory and file within it and all symlinks in a build step for both OS X and Linux:

[code] // Create the real directory and file first:

Call DoShellCommand( "/bin/mkdir " + CurrentBuildLocation + “/TestDir” )
Call DoShellCommand( "/bin/echo TestFileA >> " + CurrentBuildLocation + “/TestDir/TestFileA” )

// Now create the symlink to the directory and the file within:

Call DoShellCommand( "/bin/ln -s -f " + CurrentBuildLocation + "/TestDir " + CurrentBuildLocation + “/TestDir-SymLink” )
Call DoShellCommand( "/bin/ln -s -f " + CurrentBuildLocation + "/TestDir/TestFileA " + CurrentBuildLocation + “/TestFileA-Symlink” )
[/code]

The Xojo docs reports that the .child method should resolve all symbolic links on OS X and Linux, but then how should I get a file that is within that folderitem that was created with a .child(“SymLink-DirName-Here”) ?

2

after the build step & the app launches what does ls -al show for those links ?

3

Use folderitem.item() to follow the link to the target, and use the target in your path.

[code] dim mSymLinkDir as folderitem = specialfolder.desktop.child(“TestDir-SymLink”)
dim d as folderitem = mSymLinkDir.item(1)
mSymLinkDir = d.Parent //this contains the target folder folderitem
dim mSymlinkFileInDir as FolderItem = mSymLinkDir.Child(“TestFileA-Symlink”)
if mSymlinkFileInDir.Exists = true then msgbox “It exists”

[/code]

If the target directory is empty, you may need to create an item in there first to get the name of the target, then delete it afterwards. In our example TestFileA-Symlink is already there, so it is not necessary.

4

Well one issue is that the symlink for

dim mSymlinkFileInDir as FolderItem = mSymLinkDir.Child("TestFileA-Symlink") is not inside the dir that the symlink points to
Its right next to the other symlink

So with your code it fails to find the file IN the dir pointed to by the symlink

dim mSymLinkDir as FolderItem = mAppFolder.Child("TestDir-SymLink")
BUT with this code it finds it

dim mSymLinkDir as FolderItem = mAppFolder.Child("TestDir-SymLink") dim mSymlinkFileInDir as FolderItem = mAppFolder.Child("TestFileA-Symlink")

5

I’m seeing an odd bug on Linux where after I use .Child(“dirName”) the last character in the path of the folderitem gets truncated.

Yes, I’m sure. Yes, it’s odd.

I’ll work on getting a sample project prepared for a bug report in the next few days.

6

I can see this too.

Linux / Ubuntu 12.04, Xojo 2015r2.4

I’m trying to walk the /sys/bus/usb/devices tree.
This is what I have:
/sys/bus/usb/devices contains

  • usb1 -> …/…/…/devices/pci0000:00/0000:00:0b.0/usb1

This gets turned into:
/sys/bu/devices/pci0000:00/0000:00:0b.0/usb1
^ "/bu"shouldn’t be there

If I write it out by hand the full name would be
/sys/bus/usb/devices/…/…/…/devices/pci0000:00/0000:00:0b.0/usb1

/
sys/
bus/ ( 3 >>)
usb/ ( 2 >>)
devices/ ( 1 >>)
…/ ( 1 <<)
…/ ( 2 <<)
…/ ( 3 <<)
devices/pci0000:00/0000:00:0b.0/usb1

The spurious “/bu” makes me think something is trying to “normalize” the path but forgetting to count the “/” in fixing the prefix.