I'm sorry to be slightly off topic, when it comes to this list, but I have no clue where to look for that and I think it can be doe on kernel level only.
In short - I've got bunch of applications running both on windows and linux and these applications exchange links to files mounted on both sides. The problem is that these paths are different, i.e. like D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need is unifying them. So my idea is to have path translator on anything on kernel level, which will make Linux open call to D:/dir/file on Linux work and open /mountpoint/dir/file. Was anything close to that ever incorporated in kernel?
Applications are, as usual, closed source, and support for them, also as usual, answers "won't be fixed, switch to Windows, please". Very helpful.
Any other ideas of solving this problem are also warmly welcomed. Also on windows side.
----------------------------------------------------------------------
Nie szukam kochanka!
>> http://link.interia.pl/f1eeb
[email protected] wrote:
> I'm sorry to be slightly off topic, when it comes to this list, but I have
> no clue where to look for that and I think it can be doe on kernel level
> only.
>
> In short - I've got bunch of applications running both on windows and
> linux and these applications exchange links to files mounted on both
> sides. The problem is that these paths are different, i.e. like
> D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need is
> unifying them. So my idea is to have path translator on anything on kernel
> level, which will make Linux open call to D:/dir/file on Linux work and
> open /mountpoint/dir/file. Was anything close to that ever incorporated in
> kernel?
Um, no.
More likely solutions are ptrace (intercept system calls using debugging
interface) or similar LD_PRELOAD magic (see fakeroot for an example).
> Applications are, as usual, closed source, and support for them, also as
> usual, answers "won't be fixed, switch to Windows, please". Very helpful.
>
> Any other ideas of solving this problem are also warmly welcomed. Also on
> windows side.
I thought modern windows supported unix-like mounts, a bit like the old
SUBST.EXE in dos. So you could then mount all other drive letters as
subdirectories on the main drive. Don't ask me how to do it though :-).
Alan
> In short - I've got bunch of applications running both on windows and linux and these applications \
> exchange links to files mounted on both sides. The problem is that these paths are different, i.e. like \
> D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need is unifying them. So my idea is to \
> have path translator on anything on kernel level, which will make Linux open call to D:/dir/file on Linux \
> work and open /mountpoint/dir/file. Was anything close to that ever incorporated in kernel?
What's wrong with just:
# mkdir -p /D:/dir
# mount.cifs ...
# touch /D:/dir/file
?
Or, use symlinks from /D:/dir to /mountpoint/dir/
--
Tomasz Chmielewski
http://wpkg.org
Tomasz Chmielewski wrote:
>> In short - I've got bunch of applications running both on windows and
>> linux and these applications \
>> exchange links to files mounted on both sides. The problem is that
>> these paths are different, i.e. like \
>> D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need
>> is unifying them. So my idea is to \
>> have path translator on anything on kernel level, which will make
>> Linux open call to D:/dir/file on Linux \
>> work and open /mountpoint/dir/file. Was anything close to that ever
>> incorporated in kernel?
>
> What's wrong with just:
>
> # mkdir -p /D:/dir
> # mount.cifs ...
> # touch /D:/dir/file
>
> ?
>
> Or, use symlinks from /D:/dir to /mountpoint/dir/
That only works from the root directory though. In unix, "C:/" is a
relative path.
Alan
Alan Jenkins wrote:
> Tomasz Chmielewski wrote:
>>> In short - I've got bunch of applications running both on windows and
>>> linux and these applications \
>>> exchange links to files mounted on both sides. The problem is that
>>> these paths are different, i.e. like \
>>> D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need
>>> is unifying them. So my idea is to \
>>> have path translator on anything on kernel level, which will make
>>> Linux open call to D:/dir/file on Linux \
>>> work and open /mountpoint/dir/file. Was anything close to that ever
>>> incorporated in kernel?
>>
>> What's wrong with just:
>>
>> # mkdir -p /D:/dir
>> # mount.cifs ...
>> # touch /D:/dir/file
>>
>> ?
>>
>> Or, use symlinks from /D:/dir to /mountpoint/dir/
> That only works from the root directory though. In unix, "C:/" is a
> relative path.
Yeah, creating "C:" symlink in each and every directory accessed by the
application doesn't sound like a neat solution.
BTW, it's the first time I hear about a unix application which has paths
like D:/ or C:/ hardcoded.
--
Tomasz Chmielewski
http://wpkg.org
On Fri, Aug 29, 2008 at 10:50:51AM +0200, Tomasz Chmielewski wrote:
> Alan Jenkins wrote:
>
>> Tomasz Chmielewski wrote:
>>>> In short - I've got bunch of applications running both on windows and
>>>> linux and these applications \
>>>> exchange links to files mounted on both sides. The problem is that
>>>> these paths are different, i.e. like \
>>>> D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need
>>>> is unifying them. So my idea is to \
>>>> have path translator on anything on kernel level, which will make
>>>> Linux open call to D:/dir/file on Linux \
>>>> work and open /mountpoint/dir/file. Was anything close to that ever
>>>> incorporated in kernel?
>>>
>>> What's wrong with just:
>>>
>>> # mkdir -p /D:/dir
>>> # mount.cifs ...
>>> # touch /D:/dir/file
>>>
>>> ?
>>>
>>> Or, use symlinks from /D:/dir to /mountpoint/dir/
>> That only works from the root directory though. In unix, "C:/" is a
>> relative path.
>
> Yeah, creating "C:" symlink in each and every directory accessed by the
> application doesn't sound like a neat solution.
current working directory, actually. Which means you don't necessarily have
to use the filesystem root but only a proper start directory for these
mounts/links. But yeah, we don't know if said proprietary application
does/doesn't cwd() to it.
I suggest extending this mess a bit:
# mkdir -p /server/share
# mount.cifs ...
and use UNC paths. '//server/share/dir/file.txt' will work out nicely :-)
Thorsten.
> BTW, it's the first time I hear about a unix application which has paths
> like D:/ or C:/ hardcoded.
>
>
> --
> Tomasz Chmielewski
> http://wpkg.org
--
| Thorsten Kranzkowski Internet: [email protected] |
| Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [email protected] [44.130.8.19] |
<kovlensky <at> interia.pl> writes:
[irony]
> Applications are, as usual, closed source, and support for them, also as
> usual, answers "won't be fixed, switch to Windows, please". Very helpful.
Name the app, so we know what to avoid ... :J
[/irony]
>
> Any other ideas of solving this problem are also warmly welcomed. Also on
> windows side.
>
Look how WINE does this - maybe run the Windows native under Linux+WINE would
help ?
el es
All,
Thank you for massive support. First - all of you miss one important issue - slash/backlash conversion, when transferring path from Linux to Windows and back. Second - that's corporate with tens of people relying on these systems running. Answering questions about application - that's big engineering one, with port existing on many os'es. Objects, which are created there, point to physical files on disk. It's like symlink. One symlink per object. As these symlinks are simply single paths to file I find it impossible to develop any method of having a link working on both Linux and Windows. Also writing anything on my own won't work - I know that it can be done with LD_PRELOAD for example, but try convincing big corporation that their development-critical environment can safely rely on your custom piece of code...
Many suggestions were very helpful, but, unfortunately, looks like no real linux world approved solution exisits.
Regards,
Zdenek
Alan Jenkins napisa?(a):
> [email protected] wrote:
>
> > I'm sorry to be slightly off topic, when it comes to this list, but I
> have
> > no clue where to look for that and I think it can be doe on kernel
> level
> > only.
> >
> > In short - I've got bunch of applications running both on windows and
> > linux and these applications exchange links to files mounted on both
> > sides. The problem is that these paths are different, i.e. like
> > D:/dir/file on windows and /mountpoint/dir/file on Linux. What I need
> is
> > unifying them. So my idea is to have path translator on anything on
> kernel
> > level, which will make Linux open call to D:/dir/file on Linux work and
> > open /mountpoint/dir/file. Was anything close to that ever incorporated
> in
> > kernel?
>
> Um, no.
>
> More likely solutions are ptrace (intercept system calls using debugging
> interface) or similar LD_PRELOAD magic (see fakeroot for an example).
>
> > Applications are, as usual, closed source, and support for them, also
> as
> > usual, answers "won't be fixed, switch to Windows, please". Very
> helpful.
> >
> > Any other ideas of solving this problem are also warmly welcomed. Also
> on
> > windows side.
>
> I thought modern windows supported unix-like mounts, a bit like the old
> SUBST.EXE in dos. So you could then mount all other drive letters as
> subdirectories on the main drive. Don't ask me how to do it though :-).
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
----------------------------------------------------------------------
Tani telefon!
Sprawdz >>> http://link.interia.pl/f1ef5
On Fri, Aug 29, 2008 at 12:54:20PM +0200, [email protected] wrote:
> All,
>
> Thank you for massive support. First - all of you miss one important issue - slash/backlash conversion, when transferring path from Linux to Windows and back. Second - that's corporate with tens of people relying on these systems running. Answering questions about application - that's big engineering one, with port existing on many os'es. Objects, which are created there, point to physical files on disk. It's like symlink. One symlink per object. As these symlinks are simply single paths to file I find it impossible to develop any method of having a link working on both Linux and Windows. Also writing anything on my own won't work - I know that it can be done with LD_PRELOAD for example, but try convincing big corporation that their development-critical environment can safely rely on your custom piece of code...
If they have port to many OSes, they have dealt with that before and
solution used for e.g. Solaris would very likely be a good start...