Mtime possibly not uptodate in network.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Mtime possibly not uptodate in network.

Stef Bon-2
Hi,

with a network fs I'm working on comparing the file on the remote
server has been changed.
When attributes are received from the server, these are compared with
the cached ones. When the
mtim on the server is later, the file has been changed, and local
cache should be ignored
when opening the file (by not using the FOPEN_KEEP_CACHE).

Now I run into a problem, the mtime in my local cache is set to the
moment the attributes are created in my cache, and this may not be the
same as the mtime on the server, because creation and writing to files
may take some (short) time, and when the server sets the mtime -after-
that, there is a problem.
Now when my fuse client compares after a lookup or getattr (which is
always done before an open )
it will find they differ, and will not make use of the local cache,
while the remote file has not been changed compared to the local
cache.

Howto deal with this?
I see in the logfiles that after the create call, and bytes have been
written, and the file is released, a lookup is done. Well that's a
good thing to see, since than it's possible to set the cached mtime
value to the one received from the server.
Is it always the case that after bytes are written to a remote file
and the release, a lookup is done?

I hope you understand the problem. If not I try to will explain.
Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Jean-Pierre André
Stef Bon wrote:

> Hi,
>
> with a network fs I'm working on comparing the file on the remote
> server has been changed.
> When attributes are received from the server, these are compared with
> the cached ones. When the
> mtim on the server is later, the file has been changed, and local
> cache should be ignored
> when opening the file (by not using the FOPEN_KEEP_CACHE).
>
> Now I run into a problem, the mtime in my local cache is set to the
> moment the attributes are created in my cache, and this may not be the
> same as the mtime on the server, because creation and writing to files
> may take some (short) time, and when the server sets the mtime -after-
> that, there is a problem.

If you have to compare local times to remote times,
you are bound to have problems.

This reminds me of a patch I had to apply to "make"
long ago for compiling source files on a remote nfs
server with object files created locally...

The fuse_reply_create() returned to the kernel has
an argument for the mtime measured on the remote server.
IMHO this the mtime to enter into the cache on create.

Jean-Pierre

> Now when my fuse client compares after a lookup or getattr (which is
> always done before an open )
> it will find they differ, and will not make use of the local cache,
> while the remote file has not been changed compared to the local
> cache.
>
> Howto deal with this?
> I see in the logfiles that after the create call, and bytes have been
> written, and the file is released, a lookup is done. Well that's a
> good thing to see, since than it's possible to set the cached mtime
> value to the one received from the server.
> Is it always the case that after bytes are written to a remote file
> and the release, a lookup is done?
>
> I hope you understand the problem. If not I try to will explain.
> Stef



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Stef Bon-2
2016-12-07 18:55 GMT+01:00 Jean-Pierre André <[hidden email]>:
> Stef Bon wrote:

>> may take some (short) time, and when the server sets the mtime -after-
>> that, there is a problem.
>
> If you have to compare local times to remote times,
> you are bound to have problems.
>
> This reminds me of a patch I had to apply to "make"
> long ago for compiling source files on a remote nfs
> server with object files created locally...
>
> The fuse_reply_create() returned to the kernel has
> an argument for the mtime measured on the remote server.
> IMHO this the mtime to enter into the cache on create.
>

That's right, but the problem is that the mtime the server handles is
not available here, only the mtime
created on the local host. They can differ. The point is that the
server protocol gives me the ability
to set attributes when creating files (sftp, see:
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-8.1
).
but do they have the same value  when data has been written to the
file from the same host, using the handle
created by the create command.
A sollution is to get the attributes owner,group,atime,ctime and mtime
with a fgetattr call (the handle is available)
when releasing the file, just before closing the handle.
This is a safe sollution, but when looking to the logfiles a see a
lookup call immediatly after the file release. It looks like the
kernel
is also interested in how the attributes are at that moment (after
changing the file). Can someone confirm this behaviour?

Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Maxim Patlasov-3
In reply to this post by Stef Bon-2
On 12/07/2016 07:44 AM, Stef Bon wrote:

> Hi,
>
> with a network fs I'm working on comparing the file on the remote
> server has been changed.
> When attributes are received from the server, these are compared with
> the cached ones. When the
> mtim on the server is later, the file has been changed, and local
> cache should be ignored
> when opening the file (by not using the FOPEN_KEEP_CACHE).
>
> Now I run into a problem, the mtime in my local cache is set to the
> moment the attributes are created in my cache, and this may not be the
> same as the mtime on the server, because creation and writing to files
> may take some (short) time, and when the server sets the mtime -after-
> that, there is a problem.
> Now when my fuse client compares after a lookup or getattr (which is
> always done before an open )
> it will find they differ, and will not make use of the local cache,
> while the remote file has not been changed compared to the local
> cache.
>
> Howto deal with this?

You must ignore those mtime-s implicitly generated by your client and
server and honor only the kernel local mtime. The rules of the game is
very simple:

1) When a file is initially created, the kernel local mtime is
initialized by the value your userspace fs wrote in out.args of
FUSE_CREATE. This value is fully under your control. Probably, it's the
same as Jean-Pierre wrote about.
2) If file already exists, the kernel local mtime is initialized by the
value your userspace fs wrote in out.args of FUSE_LOOKUP. This is also
under your control.
3) On each write, kernel updates the mtime and flushes it from time to
time by FUSE_SETATTR with inarg.valid = FATTR_MTIME. The flush is
guaranteed on fsync(2) and close(2).

So you can either to suppress implicit mtime updates in your fs like
this: mtime = get_mtime(), write, set_mtime(mtime). Or keep mtime stored
in a separate dedicated place (not affected by writes).

Thanks,
Maxim

> I see in the logfiles that after the create call, and bytes have been
> written, and the file is released, a lookup is done. Well that's a
> good thing to see, since than it's possible to set the cached mtime
> value to the one received from the server.
> Is it always the case that after bytes are written to a remote file
> and the release, a lookup is done?
>
> I hope you understand the problem. If not I try to will explain.
> Stef
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Stef Bon-2
2016-12-07 23:21 GMT+01:00 Maxim Patlasov <[hidden email]>:
> On 12/07/2016 07:44 AM, Stef Bon wrote:
>

>
>
> You must ignore those mtime-s implicitly generated by your client and server
> and honor only the kernel local mtime. The rules of the game is very simple:
>
> 1) When a file is initially created, the kernel local mtime is initialized
> by the value your userspace fs wrote in out.args of FUSE_CREATE. This value
> is fully under your control. Probably, it's the same as Jean-Pierre wrote
> about.
> 2) If file already exists, the kernel local mtime is initialized by the
> value your userspace fs wrote in out.args of FUSE_LOOKUP. This is also under
> your control.
> 3) On each write, kernel updates the mtime and flushes it from time to time
> by FUSE_SETATTR with inarg.valid = FATTR_MTIME. The flush is guaranteed on
> fsync(2) and close(2).
>

1) I know the kernel mtime is initialized by the fuse_entry_out reply
when a file is created.
The problem is only the create does not know the mtime the server uses.
2) Yes I know.
3) Good to know.

When I think about this more, the problem is that there is a
possiblity that there is difference in
the clocks of client and server and possibly a difference in the
handling of mtime by the client and the server.
I cannot ignore the mtime generated by the server as you suggest,
since it's a networkfilesystem, and others can
change files as well, which has an effect on the mtime of the files on
the server. I want my fs
is able to compare local mtime with the mtime of a file on the server
to decide the cache is still valid
(=the file is not changed). for using the FOPEN_KEEP_CACHE flag on open.

Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Maxim Patlasov-3
On 12/07/2016 04:06 PM, Stef Bon wrote:

> 2016-12-07 23:21 GMT+01:00 Maxim Patlasov <[hidden email]>:
>> On 12/07/2016 07:44 AM, Stef Bon wrote:
>>
>>
>> You must ignore those mtime-s implicitly generated by your client and server
>> and honor only the kernel local mtime. The rules of the game is very simple:
>>
>> 1) When a file is initially created, the kernel local mtime is initialized
>> by the value your userspace fs wrote in out.args of FUSE_CREATE. This value
>> is fully under your control. Probably, it's the same as Jean-Pierre wrote
>> about.
>> 2) If file already exists, the kernel local mtime is initialized by the
>> value your userspace fs wrote in out.args of FUSE_LOOKUP. This is also under
>> your control.
>> 3) On each write, kernel updates the mtime and flushes it from time to time
>> by FUSE_SETATTR with inarg.valid = FATTR_MTIME. The flush is guaranteed on
>> fsync(2) and close(2).
>>
> 1) I know the kernel mtime is initialized by the fuse_entry_out reply
> when a file is created.
> The problem is only the create does not know the mtime the server uses.

Why the create doesn't know? Because you firstly create file locally and
only later transfer it to the server? If yes, then you only need to
transfer local mtime along with the file itself.

> 2) Yes I know.
> 3) Good to know.
>
> When I think about this more, the problem is that there is a
> possiblity that there is difference in
> the clocks of client and server and possibly a difference in the
> handling of mtime by the client and the server.
> I cannot ignore the mtime generated by the server as you suggest,
> since it's a networkfilesystem, and others can
> change files as well, which has an effect on the mtime of the files on
> the server.

I guess you'll need to synchronize times across server and clients
anyway. I.e. independently on how FUSE protocol works.

> I want my fs
> is able to compare local mtime with the mtime of a file on the server
> to decide the cache is still valid
> (=the file is not changed). for using the FOPEN_KEEP_CACHE flag on open.

What exactly will be broken if you implement the following scheme: when
your fs creates new file, initial mtime is whatever you like, then you
handle mtime according to "3)" above? In the other words, you update
client-cache and server mtime *only* on explicit FUSE_SETATTR with
inarg.valid = FATTR_MTIME?

The scheme above has a cache coherency problem when several clients
update the same file simultaneously, but you won't solve it without
incompatible change of FUSE protocol anyway.

Thanks,
Maxim


>
> Stef


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Jean-Pierre André
In reply to this post by Stef Bon-2
Stef Bon wrote:

> 2016-12-07 23:21 GMT+01:00 Maxim Patlasov <[hidden email]>:
>> On 12/07/2016 07:44 AM, Stef Bon wrote:
>>
>
>>
>>
>> You must ignore those mtime-s implicitly generated by your client and server
>> and honor only the kernel local mtime. The rules of the game is very simple:
>>
>> 1) When a file is initially created, the kernel local mtime is initialized
>> by the value your userspace fs wrote in out.args of FUSE_CREATE. This value
>> is fully under your control. Probably, it's the same as Jean-Pierre wrote
>> about.
>> 2) If file already exists, the kernel local mtime is initialized by the
>> value your userspace fs wrote in out.args of FUSE_LOOKUP. This is also under
>> your control.
>> 3) On each write, kernel updates the mtime and flushes it from time to time
>> by FUSE_SETATTR with inarg.valid = FATTR_MTIME. The flush is guaranteed on
>> fsync(2) and close(2).
>>
>
> 1) I know the kernel mtime is initialized by the fuse_entry_out reply
> when a file is created.
> The problem is only the create does not know the mtime the server uses.
> 2) Yes I know.
> 3) Good to know.
>
> When I think about this more, the problem is that there is a
> possiblity that there is difference in
> the clocks of client and server and possibly a difference in the
> handling of mtime by the client and the server.
> I cannot ignore the mtime generated by the server as you suggest,
> since it's a networkfilesystem, and others can
> change files as well, which has an effect on the mtime of the files on
> the server. I want my fs
> is able to compare local mtime with the mtime of a file on the server
> to decide the cache is still valid
> (=the file is not changed). for using the FOPEN_KEEP_CACHE flag on open.

When comparing times, do not forget that local and remote
may have different resolutions (one second, one nanosecond,
100 nanoseconds, etc.). A file created remotely when local
time is 12:34:56.789 may appear as having been created remotely
earlier at 12:34:56:000.

FWIW, for solving the old "make" issue (this was before ntp),
I had to consider that created files got a timestamp which
was the maximum of current local time and all the timestamps
encountered so far. This was inspired by the CACM 1978 article
by Leslie Lamport about ordering of events in distributed
systems. Maybe this is what you need.

Jean-Pierre



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Stef Bon-2
2016-12-08 8:53 GMT+01:00 Jean-Pierre André <[hidden email]>:
>> to decide the cache is still valid
>> (=the file is not changed). for using the FOPEN_KEEP_CACHE flag on open.
>
> When comparing times, do not forget that local and remote
> may have different resolutions (one second, one nanosecond,
> 100 nanoseconds, etc.). A file created remotely when local
> time is 12:34:56.789 may appear as having been created remotely
> earlier at 12:34:56:000.
>

Yes I know. The filesystem is sftp, and not all versions of that protocol
support nanoseconds precision. See for an overview on:

http://www.greenend.org.uk/rjk/sftp/sftpversions.html

Note the sftp server used by openssh uses protocol 3, and thus is not
using the nanosecond precision.

> FWIW, for solving the old "make" issue (this was before ntp),
> I had to consider that created files got a timestamp which
> was the maximum of current local time and all the timestamps
> encountered so far. This was inspired by the CACM 1978 article
> by Leslie Lamport about ordering of events in distributed
> systems. Maybe this is what you need.

Sure what Maxim said about time synchronization, in the ideal world
all compters are synchronized. In reality I cannot rule out that computers
aren't. And it's not direct FUSE no, but when working on a network
filesystem you have to deal with this I think.

I've found a sollution for this: get the difference between local and
remote time by
(note I'm using sftp on ssh, I have already a working ssh connection,
and I can run commands on the server):

- client send the command "date +%s.%N" to the server, and notes the
(local) time it's send in time_send
- the server receives this and runs tyhe command and sends the output back
- client recives this output and keeps the time in time_received

now to get the difference in time in seconds:

( time_received + time_send) / 2 = "output command" + delta

The delta is the difference in seconds, and to use a correction when
times are send or received over the wire.
This is not exactly true, but it's a good estimation.
And maybe it's good thing to send this command frequently to the
server. This has the positive sideeffect
to prevent the server will disconnect cause of lack of traffic (some
servers use idle timeout).

Thanks all Jean-Pierre and Maxim,

Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Nikolaus Rath
On Dec 08 2016, Stef Bon <[hidden email]> wrote:

> 2016-12-08 8:53 GMT+01:00 Jean-Pierre André <[hidden email]>:
>>> to decide the cache is still valid
>>> (=the file is not changed). for using the FOPEN_KEEP_CACHE flag on open.
>>
>> When comparing times, do not forget that local and remote
>> may have different resolutions (one second, one nanosecond,
>> 100 nanoseconds, etc.). A file created remotely when local
>> time is 12:34:56.789 may appear as having been created remotely
>> earlier at 12:34:56:000.
>>
>
> Yes I know. The filesystem is sftp, and not all versions of that protocol
> support nanoseconds precision. See for an overview on:

Just to make sure, you know that there is already an sftp implementation
for FUSE, right? https://github.com/libfuse/sshfs. It just so happens
that it is also in urgent need of some attention...


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Stef Bon-2
2016-12-08 17:48 GMT+01:00 Nikolaus Rath <[hidden email]>:
>> Yes I know. The filesystem is sftp, and not all versions of that protocol
>> support nanoseconds precision. See for an overview on:
>
> Just to make sure, you know that there is already an sftp implementation
> for FUSE, right? https://github.com/libfuse/sshfs. It just so happens
> that it is also in urgent need of some attention...
>

Yes I know. I want things which are not possible with sshfs.

If there are issues I'm willing to look at those.

Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Nikolaus Rath
On Dec 08 2016, Stef Bon <[hidden email]> wrote:

> 2016-12-08 17:48 GMT+01:00 Nikolaus Rath <[hidden email]>:
>>> Yes I know. The filesystem is sftp, and not all versions of that protocol
>>> support nanoseconds precision. See for an overview on:
>>
>> Just to make sure, you know that there is already an sftp implementation
>> for FUSE, right? https://github.com/libfuse/sshfs. It just so happens
>> that it is also in urgent need of some attention...
>>
>
> Yes I know. I want things which are not possible with sshfs.

Out of curiosity: what things?


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Stef Bon-2
2016-12-09 0:22 GMT+01:00 Nikolaus Rath <[hidden email]>:

>>
>> Yes I know. I want things which are not possible with sshfs.
>
> Out of curiosity: what things?
>

My fs creates a ssh session and has the abilty to open a channel to the server.
One channel is used for the sftp subsystem (for the filesystem), other
channels can be used to run a command on the server
(for getting the time on the server for example, see above, or the
groupname of the connecting user for mapping).
This is not possible with sshfs.
Next I do not see version handling in sshfs. There are different sftp
servers, the sftp server provided by openssh only supports version 3
of the sftp protocol.
See http://www.greenend.org.uk/rjk/sftp/sftpversions.html
the best version is 6, proving much more features.
(I'm using the server found also there, gesftpserver.)

For example I'm working on making locks work, and possibly acl
checking, both require the last version,
(and on the long term setting of leases and fsnotify (both first
support in FUSE)).

Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Nikolaus Rath
On Dec 09 2016, Stef Bon <[hidden email]> wrote:

> 2016-12-09 0:22 GMT+01:00 Nikolaus Rath <[hidden email]>:
>
>>>
>>> Yes I know. I want things which are not possible with sshfs.
>>
>> Out of curiosity: what things?
>>
>
> My fs creates a ssh session and has the abilty to open a channel to the server.
> One channel is used for the sftp subsystem (for the filesystem), other
> channels can be used to run a command on the server
> (for getting the time on the server for example, see above, or the
> groupname of the connecting user for mapping).
> This is not possible with sshfs.

Uh, ok. But in what situation would the filesystem want to run a command
on the remote server?

> Next I do not see version handling in sshfs. There are different sftp
> servers, the sftp server provided by openssh only supports version 3
> of the sftp protocol.
> See http://www.greenend.org.uk/rjk/sftp/sftpversions.html
> the best version is 6, proving much more features.
> (I'm using the server found also there, gesftpserver.)

Getting support for that in sshfs as well would actually be very
welcome...


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mtime possibly not uptodate in network.

Stef Bon-2
2016-12-09 18:47 GMT+01:00 Nikolaus Rath <[hidden email]>:

> Uh, ok. But in what situation would the filesystem want to run a command
> on the remote server?

Well like I mentioned earlier in this posts I want my client to
discover the remote group
the connecting user is part of, to get a better mapping of users
between server and client.

And to get the time on the server, to know there is a significant
difference in time between server and client.

>
>
> Getting support for that in sshfs as well would actually be very
> welcome...
>
I will look to sshfs. See I can fix some issues, but I seen some
enhanced programming like in sshnodelay.c
I do not understand.... something with dlsym and RTLD_NEXT. ugh.

Stef

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel