Unable to read relative path in Windows machine

[johardi]

[8/12/16, 12:27:55 PM] Bob Dionne: just found another platform issue [8/12/16, 12:29:08 PM] Bob Dionne: when we edit the metaproject using a windows machine…. [8/12/16, 12:29:41 PM] Bob Dionne: the file path name used in the project for the history file will be a windows path name

15:10:58 [XNIO-3 task-5] ERROR - [Request from root (Root User) - Open project] Unable to access history file in remote server
org.protege.editor.owl.server.versioning.InvalidHistoryFileException: Cannot found history file at path root\data\80bf9029-b543-49c8-b544-67b6f63c862d\ncit-owl2-remote.history

[bdionne]

I think this is a dup? - https://github.com/protegeproject/metaproject/issues/4

Pretty sure the problem was backslashes in the file path, not the inability for windows to find it, though that might be a separate issue.

I'll check with Gilberto on what the issue actually was, I don't have a windows machine

[johardi]

Looking at the error message, it seems we are using the correct backslash for Windows. Now the server will get an absolute path instead of a relative path. Hopefully, Gilberto can confirm the fix.

[...] Cannot found history file at path root\data\80bf9029-b543-49c8-b544-67b6f63c862d\ncit-owl2-remote.history

[bdionne]

hmm, looking at the code, the project file path is created on the server side, so it will be that OS that determines the path separator.

[bdionne]

This is the issue Gilberto was mentioning in status today. It may be a protege-client bug

[johardi]

I'm considering to have an extra server parameter for server architecture = { UNIX, WIN }

[rsgoncalves]

This should be fixed after -server and -client are refactored with https://github.com/protegeproject/metaproject/tree/project-api-refactor

[bdionne]

I looked at this refactor to switch to strings and I'm not sure it's ideal.

It turns out that we're overloading the File object in the Project class. On the client we're using it to create a project which stores the client owl file being uploaded. On the server we're using it to hold the location of the history file. This path is only needed on the server, and is created by the server using bits it has at hand, namely the project id, name, and server root. The client should never see this file.

So I took a pass at removing the File object completely from the metaproject, and made the requisite changes to the client and server to match.

It seems fine so far, I'll test it for a few days first. The changes to the client and admin gui were minimal, mainly explicitly passing the file to upload to the client.

[johardi]

There is a misuse when applying the parameter File to create the Project instance. That file field should hold the information about the history file, and not OWL file. With this setting, the initial creation of the Project instance should happen on the server, not on the client. We're planning to fix this issue with the protege-api-refactor branch.

[...] The client should never see this file.

Your concern is the same as ours, which underlying the decision to have the Project to carry the string of the history file location rather than the File instance.

[bdionne]

I agree that it's a misuse, or overloading. The thing I noticed though is that the File object doesn't need to be there at all. It's really a server side item and shouldn't leak out to the client.

[rsgoncalves]

With the current approach there is no explicit need to have the project File or filePath String in the Project. It is there because it made sense with our original approach that only created metaproject objects on the server side, rather than both on the client and server. I made it Optional in the protege-api-refactor branch to cater to both scenarios, and so that we can more easily revert back the code to the live-configuration-editing mode without API changes.

[bdionne]

right, I recall it's legacy origins in the RMI version. I'm curious though as to what use case would warrant exposing this file path string, even in the live-configuration-editing mode. It also seems brittle exposing details of where files are stored to the users. Why would they care about this detail? In the live-configuration-editing mode do you see users editing this field?

[rsgoncalves]

In my opinion there should be some reference to the file that corresponds to the project. The history file is named after the project, e.g., project X will result in the creation of a file X.history. Now:

• If I rename the project, further down the line I (or other users) would not know what file corresponds to project X.
• If I delete the project from the UI and skip deleting the file, I may not know what file to delete later on.

If the file path reference is not exposed somehow, I have no chance of doing the above operations properly, so this piece of information is certainly useful for admin users. And it is already implemented! For general users this detail doesn't matter (and doesn't hurt - there's nothing I can do with that detail as a user) since they won't access to the admin tab. So I don't see why go through the effort of removing it. By removing the file path reference, what's your strategy to deal with the code below that uses that reference?

• https://github.com/protegeproject/protege-server/blob/http-metaproject-integration/src/main/java/org/protege/editor/owl/server/change/ChangeManagementFilter.java#L52
• https://github.com/protegeproject/protege-server/blob/http-metaproject-integration/src/main/java/org/protege/editor/owl/server/http/handlers/MetaprojectHandler.java#L245
• https://github.com/protegeproject/protege-server/blob/http-metaproject-integration/src/main/java/org/protege/editor/owl/server/http/handlers/MetaprojectHandler.java#L213
• https://github.com/protegeproject/protege-server/blob/http-metaproject-integration/src/main/java/org/protege/editor/owl/server/base/ProtegeServer.java#L199
• https://github.com/protegeproject/protege-server/blob/http-metaproject-integration/src/main/java/org/protege/editor/owl/server/base/ProtegeServer.java#L248

I see what you've done here. I'm pretty sure that if I rename a project the code will break when executing this line. The code does not account for the possibility that a user can change a project's name. If or when that happens, the code won't be able to fetch the project file because it's using the altered project name to fetch it, which has no correspondence to a file in the file system since the file itself does not get renamed.

All that said, what do you think are the actual benefits of this change?

[bdionne]

Well the primary benefit is that it fixes an immediate bug that was causing users pain.

I agree that there needs to be a way to map a project to the filesystem, and for that purpose the id of the project, presumably immutable, should suffice, non?

Using the concatentation of three pieces of data (server root dir, id, and name) is brittle. It's also a simple computation, easily done in memory when needed with the pieces at hand, so it's, IMHO fragile to memorialize it as a string exposed to users.

Yes, it's a problem when the name changes, it won't break the code, but the project name and file name will be out of sync. The project name should just not be used at all to name anything in the file system if it can be modified. As I mentioned above the id together with the server root should suffice, something like root/data/<xxxxxx>/<xxxxxx>.history