I know you must have seen the error while using LCM for Reporting and Analysis objects.
If the pass is too long it’ll throw an error message complaining about path more than 256 characters.
I was working on a client where I got the same issue. (The users had a long way to go to view the reports 😉 )
If you are not aware of Reporting structure here is what it does. (or I think what it does ;))
When you create a report, it adds an entry (more entries, we’ll stick with one for now) in V8_CONTAINER table and then stores the report in a physical location. (this is the data folder location you select while configuring BI+)
Data folder
This is the entry for a report called “Sample”
Relational Table
This is the how it gets stored in Relational
When you change fileSystem.friendlyNames to “false”, it forces LCM to extract the reports based on their IDs (not names).
With that in mid I did follows the steps mentioned under Editing Migration Properties
Import the properties file, restarted Shared Services and LCM’ed the report again.
To my surprise it didn’t work. (I got got the names and path too long error). A little bit of research took me to the Readme of 11.1.2.2 where it is listed as Know Issues under
LCM
13862629 – Artifact export, by default, uses friendly artifact names instead of artifact IDs even if the friendly name setting is set to false.
Financial Reporting
13367741 – Some new artifacts are not identified using their friendly names.
I raised an SR to check the status and got the reply as follows
friendlynames false is not supported from 11.1.2.1 onwards. 7-zip has been the recommended approach to overcome the windows path limitation issues.So by default BI+ artifacts are saved with name and id which is the behavior as when freindlynames is set to true. The reason for disabling the false property was, during our further testing we realized in BI+ each artifact has more than one file with the same name and hence the files cannot be stored by names uniquely on the file
The response made me look at an older version (11.1.1.3) and see what were those changes and to my surprise it didn’t work there too. I do remember it was working on an earlier version. (Can’t remember which one though 
)
)I don’t see a change in how RnA stores files in the filesystem, so not sure why the property is not working.
It is great that 7zip can handle this. You can use 7zip to compress the contents and move them across servers.
I think it is high time for Oracle to clean up the documentation. (LCM guide still says friendlynames can be used)
I had the same issue and resolved it with 7-zip too. Nice to know its a documented solution
Hi celvin,
As per my knowledge it friendlyname works well in 11.1.1.3, its just not working from 11.1.2.1 or may be from 11.1.2.x family.
Another work around as per support is use unix environment as unlike windows it unzip the folders directly in the same directory where as windows first unzip to temp location first.
@shiva, I do remember that it worked on an older version. I thought it was 11.1.1.3, setup a VMImage and tried today and it is not working. It was still exporting folders with names not with UUIDs. Do you have a machine where it is works on 11.1.1.3?
nice 7-zip protector you have.
Long Path Tool is the best option to solve long path problem
I see both the report name as a file, and all of the “long file name” files in the folders (subdirs) together. Is the report name the only “real” file and the long ones previous versions of the same report? Do we know what is in the files with the long names?
I’ve tried keeping the reports, and deleting the long files, THEN migrating to the target server and it seems to work OK, but I am still testing. Thanks.
You can try opening that in Notepad ++. I think that is a report. The contents should be similar to an FR report.