Filepaths on a central database

[cov]

I'm using Firebird to store information in a database.

Currently, I'm using an embedded database so all information is stored locally.

However, I want to have multiple users access the same database over a network.

So, if a file path is F:\Project\6871\file.txt how would you store this in the database? Some users may not have the server mapped to "F".

Would you use the IP of the server? or the UID? or neither?

[lucamar]

So, if a file path is F:\Project\6871\file.txt how would you store this in the database? Some users may not have the server mapped to "F".

Would you use the IP of the server? or the UID? or neither?

If all the users form part of a Windows domain, you can use canonical UNCs names (use ExpandUNCFileName()). Otherwise, I'd convert the UNC to a URL.

[Dr.Theopolis]

I have been thinking about this very issue this week. But for me, the biggest problem is when a filepath is stored by my app on Windows, and then that filepath needs to be opened by my app on Mac or Linux.

For Windows, as mentioned in the previous post, you can use ExpandUNCFileName to get the UNC name and store that in the database. Assuming that the file is on a network drive, then when you want to access that location on other machines that have a different drive letter mapped or no drive letter mapped, those machines can access the file directly using the UNC name. In other words, things like memo1.lines.loadfromfile(filepath) will work where filepath is something like \\myserver\shared\file.txt

Also, if on the original machine the original drive letter is remapped to somewhere else, then you still have the path in your database to the original file locations.

For me, the problem is a cross-platform issue. A UNC name cannot be use directly on Mac. For example, memo1.lines.loadfromfile(filepath) won't work where filepath is //myserver/shared/file.txt or even smb://username@myserver/shared/file.txt . A volume has to be mounted first. I am still thinking through this problem but solutions I've come up with on paper are very complex. I'm trying to foresee as many scenarios as I can.

I would be very interested in hearing how others have dealt with this issue for cross-platform apps.

[lucamar]

Having a global persistent way to access  objects (files, in this case) is what URIs are all about--even BDE aliases can be seen from that perspective. The only major problem, usually, is to find a way to resolve names or ids to ressource locations.

The O.P. wanted to stored paths to files, which is why suggested UNCs or resolving them to URNs; but if I were designing an application from scratch, I wouldn't bother with that; I would store just filenames and, if really needed, a relative path in network notation from a root or UUID which is up to the program to resolve; p.e. "($root)/dinner/recipes.odt"

Of course, you may have to (re)invent a mechanism to resolve that root/uuid, but what's new about that? They did the same on networks with, p.e., DNS or KR for TCP/IP, etc.

(edit: stupid typo)