Path different between plattforms
Path different between plattforms
Hi
I am in the beginning of the trial period. My need is to organize photos and film clips and make them available for the rest of my computers in the family. This in a cross platform environment (Windows and Mac).
My setup is:
- Synology nas to store the media files
- Mac mini to host the database (Postgres) and photo supreme client
- Windows and Mac clients
I imported the media files using a Mac. I face problems to access the files from a Windows client.
When I troubleshoot I see that the path is using the format "/Volumes/folder/folder" (os x format) I import one photo from a Windows client and the path is set to "\\nas\folder\folder" (Windows format).
Did I do something wrong? I thought that this system should be cross platform?!
Please help me to understand what to do if there are something I can do to make it work or if it is not possible.
Best
Richard
I am in the beginning of the trial period. My need is to organize photos and film clips and make them available for the rest of my computers in the family. This in a cross platform environment (Windows and Mac).
My setup is:
- Synology nas to store the media files
- Mac mini to host the database (Postgres) and photo supreme client
- Windows and Mac clients
I imported the media files using a Mac. I face problems to access the files from a Windows client.
When I troubleshoot I see that the path is using the format "/Volumes/folder/folder" (os x format) I import one photo from a Windows client and the path is set to "\\nas\folder\folder" (Windows format).
Did I do something wrong? I thought that this system should be cross platform?!
Please help me to understand what to do if there are something I can do to make it work or if it is not possible.
Best
Richard
Re: Path different between plattforms
Cross platform means that you can run the application on both platforms. The way files are stored and can be accessed by an application is dictated by the Operating System. PSU is not an operating system and has to use the file system where you run the application on.
You can use "FOLDERS-Top node right click-Map to the correct physical folder" to change a Mac volume reference to a Windows volume reference...and visa versa
You can use "FOLDERS-Top node right click-Map to the correct physical folder" to change a Mac volume reference to a Windows volume reference...and visa versa
This is a user-to-user forum. If you have suggestions, requests or need support then please send a message
Re: Path different between plattforms
Hi
I dont agree on that definition of cross plattform. In my mind, cross platform is a system that are able work idependent of plattform, Photo Supreme is not since the user needs to update every time he/she change between a windows computer and a mac. Phote Supreme is one application that have one windows version and one mac version.
Anyway, this is wording. Thank you for the reply. I will now stop the testing Photo Supreme and continue to search for a DAM-system that meet my requirements.
Best
Richard
I dont agree on that definition of cross plattform. In my mind, cross platform is a system that are able work idependent of plattform, Photo Supreme is not since the user needs to update every time he/she change between a windows computer and a mac. Phote Supreme is one application that have one windows version and one mac version.
Anyway, this is wording. Thank you for the reply. I will now stop the testing Photo Supreme and continue to search for a DAM-system that meet my requirements.
Best
Richard
Re: Path different between plattforms
Hi Richard,
I have no pony in this race, but if you foreclose the option of using PSU, I think you may be denying yourself access to a fine product.
This thread got me thinking about what it means to be cross platform, so let's do some brainstorming. An operating system is traditionally considered to have 3 major components: the Kernel, the shell and the filesystem. Windows and the Mac OS certainly differ in all 3 components. In particular, the filesystem is different, including in respect to the ways that paths are designated.
To me, cross-platform means a program that can be compiled to run on more than one one platform in functional identical ways and where the data files are binary compatible on the different platforms. I don't think one can expect the data files to "know" which platform they're on. At present, the user does a one step update on the data file when moving the file from one platform to the other, so to me, PSU is actually cross platform.
To fulfill your additional requirement, the program could interrogate the data file to determine which path style it contains and update the data as needed. Alternatively, the data files could store paths in both Windows and Mac OS style and the program might be written to use the correct path data corresponding to the particular platform. The disadvantage would be added complexity in the data file tables holding the path information. I'll leave to Hert to decide whether either of these schemes is feasible or desirable.
Again--just thinking out loud. Feel free to set me straight if I've missed something obvious.
I have no pony in this race, but if you foreclose the option of using PSU, I think you may be denying yourself access to a fine product.
This thread got me thinking about what it means to be cross platform, so let's do some brainstorming. An operating system is traditionally considered to have 3 major components: the Kernel, the shell and the filesystem. Windows and the Mac OS certainly differ in all 3 components. In particular, the filesystem is different, including in respect to the ways that paths are designated.
To me, cross-platform means a program that can be compiled to run on more than one one platform in functional identical ways and where the data files are binary compatible on the different platforms. I don't think one can expect the data files to "know" which platform they're on. At present, the user does a one step update on the data file when moving the file from one platform to the other, so to me, PSU is actually cross platform.
To fulfill your additional requirement, the program could interrogate the data file to determine which path style it contains and update the data as needed. Alternatively, the data files could store paths in both Windows and Mac OS style and the program might be written to use the correct path data corresponding to the particular platform. The disadvantage would be added complexity in the data file tables holding the path information. I'll leave to Hert to decide whether either of these schemes is feasible or desirable.
Again--just thinking out loud. Feel free to set me straight if I've missed something obvious.
George
Re: Path different between plattforms
I find this discussion interesting and it raises some questions for me. I suppose that this is an issue that has arisen elsewhere before and I wonder how it is handled by other cross-platform applications. I don't use network attached storage or MAC machines myself so I never really considered the ramifications of this situation. My questions are mostly out of personal curiosity and may not contribute to a resolution of this issue but I do hope that discussing it will help me learn more and perhaps make others aware of this issue.
If I'm understanding the issue correctly, the problem seems to be that the file path, which is stored as a string in the database, is written differently depending on which operating system that the client is running on when data is created or modified in the database. Is that accurate? It seems to me that the file path should be specific to the device that's hosting the files. In this case, that is the NAS. How do disparate systems normally handle this situation? If a windows machine wants to access a file that is hosted on a device running OS X, how does it ask for that file? How do windows and Macs get files from the NAS when they are accessing them directly? Where does the translation happen? Does the NAS provide client applications that run on each device that accesses it?
I hope I'm not going off topic with my questions but understanding how this works seems to be the first step in coming up with potential resolutions. Please excuse my ignorance of cross-platform computing and file systems in general.
I'm sure this is much more complicated than I realize but I would like to understand it better.
If I'm understanding the issue correctly, the problem seems to be that the file path, which is stored as a string in the database, is written differently depending on which operating system that the client is running on when data is created or modified in the database. Is that accurate? It seems to me that the file path should be specific to the device that's hosting the files. In this case, that is the NAS. How do disparate systems normally handle this situation? If a windows machine wants to access a file that is hosted on a device running OS X, how does it ask for that file? How do windows and Macs get files from the NAS when they are accessing them directly? Where does the translation happen? Does the NAS provide client applications that run on each device that accesses it?
I hope I'm not going off topic with my questions but understanding how this works seems to be the first step in coming up with potential resolutions. Please excuse my ignorance of cross-platform computing and file systems in general.
I'm a little confused by this statement. When you say "data file" are you referring to the PSU database or the image file? I don't see how the program could interrogate the image file if it doesn't have the correct file path so I guess you mean the database. Also, when you say "update the data" do you mean modifying what is in the database? If so, is that really necessary? If the program can recognize that the path style needs to be changed, why couldn't it just do that on the fly when requesting the files? It seems wasteful to change the data every time a file is accessed by a different device.george wrote:To fulfill your additional requirement, the program could interrogate the data file to determine which path style it contains and update the data as needed.
I'm sure this is much more complicated than I realize but I would like to understand it better.
Tom Stoddard
Re: Path different between plattforms
I was referring to the database--sorry about the clumsy phrasing.Tom wrote:When you say "data file" are you referring to the PSU database or the image file?
George
Re: Path different between plattforms
I would suggest downloading a trial copy of Tuxera NTFS for Mac http://www.tuxera.com/%20Tuxera%20NTFS%20for%20Mac. That should enable your Mac to read Windows' NTFS system - though as I'm not a Mac user, I can't test it myself. I would imagine that for this to work though, your database would need to be on an NTFS drive, so that it can also be read by Windows.AxelF wrote:Please help me to understand what to do if there are something I can do to make it work or if it is not possible.
Re: Path different between plattforms
FWIW, I agree with George. Also, keep in mind that many requested (and unrequested but useful) features have been implemented in Photo Supreme along the time.george wrote: I have no pony in this race, but if you foreclose the option of using PSU, I think you may be denying yourself access to a fine product.
Regardless what the technical definition of cross platform really is (and let's keep in mind that many technical terms are not standardized), I agree that additional support for people and organizations working with multiple platforms and file systems would be beneficial.tstoddard wrote:I'm a little confused by this statement. When you say "data file" are you referring to the PSU database or the image file? I don't see how the program could interrogate the image file if it doesn't have the correct file path so I guess you mean the database. Also, when you say "update the data" do you mean modifying what is in the database? If so, is that really necessary? If the program can recognize that the path style needs to be changed, why couldn't it just do that on the fly when requesting the files? It seems wasteful to change the data every time a file is accessed by a different device.george wrote:To fulfill your additional requirement, the program could interrogate the data file to determine which path style it contains and update the data as needed.
Like Tom, I could see filepath translation working on the fly. (Yes, that would incur a run-time overhead for I/O operations - but that would be an expected price for (additional) interoperability.)
But, IMHO, an alternative way to implement the support would be to incur the overhead in the database itself. Rather than frequently updating the DB by replacing the path as needed, why couldn't the PSU catalog store info about *both* (or more) paths - and simply employ the correct one, as needed? PSU already has the Map to the correct physical folder feature - it's just that it currently works with the (limiting) assumption of only one folder description being correct. Why couldn't a user simply add a physical folder mapping (associated with a certain platform - or perhaps even with a drive serial number etc) rather than necessarily replacing the previous mapping(s)?
(Please note that PSU would not even have to enter the messy job of handling naming conventions and low-level file system details - it would still be the user's responsibility to define the correct mappings of physical folders. This said, I do realize that such a design enhancement certainly has some implications, including the use model, and may not be a trivial change to implement properly; still, I can't see why Hert couldn't pull if off if he wills.)
Any comments from Hert or someone else, please?
Re: Path different between plattforms
Hi Vlad,
The two possibilities you mentioned are exactly what I meant when I wrote
The two possibilities you mentioned are exactly what I meant when I wrote
Storing both Windows- and Mac(Unix)-style paths in the database table(s) goes against good normalization concepts. On the other hand, having the program decide which path to use on the fly might entail performance issues. While there is no strict definition of "cross-platform," I am sympathetic with the point of view that the user shouldn't have to update the database each time the user switches platforms.george, on October 27, wrote:...the program could interrogate the data file to determine which path style it contains and update the data as needed. Alternatively, the data files could store paths in both Windows and Mac OS style and the program might be written to use the correct path data corresponding to the particular platform. The disadvantage would be added complexity in the data file tables holding the path information. I'll leave to Hert to decide whether either of these schemes is feasible or desirable.
George
Re: Path different between plattforms
Hi George,
I am very sorry: for some reason I had read your previous post only superficially and missed your multiple path storage suggestion, hence its inadvertent recurrence in my previous post. Bottom line, we are on the same page.
Regards,
Vlad
I am very sorry: for some reason I had read your previous post only superficially and missed your multiple path storage suggestion, hence its inadvertent recurrence in my previous post. Bottom line, we are on the same page.
Regards,
Vlad
Re: Path different between plattforms
Hi Vlad,
No worries & no need for any apology. I wasn't trying to claim any priority by quoting myself, only that my clumsy phrasing was hard to understand. That's probably why you missed my meaning. Yes, we're on the same page. Maybe we should consider a feature request in Mantis?vlad wrote:I am very sorry: for some reason I had read your previous post only superficially and missed your multiple path storage suggestion
George
Re: Path different between plattforms
Thanks, George. May I leave you the pleasure to enter a feature request, with my vote following suit in Mantis?
Re: Path different between plattforms
Hi George, I've just added my vote.
Re: Path different between plattforms
Vlad, thanks to you and Frank who also supported this. Let's hope it's implemented, although we may have lost the OP on this thread.
George