samba - Dec 2003 - NtfsDisableLastAccessUpdate and smbmounted Win shares

Setting this dword to 1 in 
HKLM/CurrentControlSet/Control/FileSystem is supposed to
suppress updates of a file's Access Time attribute when 
browsing but even read-only accesses with NotePad or 
plain copy leave no traces.

However, if you cp or cat (or for that matter tar) a
file on an smbmounted Win share, the Access Time is
updated regardless of the setting of 
NtfsDisableLastAccessUpdate. This produces an annoying 
warning message for users of MS VC++ Studio that the 
file they've been editing had been changed by another
program and prompt them to reload it.

Does anyone know how to work around this problem?

Dragan Krnic schrieb:
> updated regardless of the setting of 
> NtfsDisableLastAccessUpdate.
This disables the access update, means read access.

If you cp this is write access, this will update the change time and i 
don't think you can disable this.

access and change update are 2 seperate fields.

>> updated regardless of the setting of 
>> NtfsDisableLastAccessUpdate.
>
> This disables the access update, means read access.
>
> If you cp this is write access, this will update the 
> change time and i don't think you can disable this.
>
> access and change update are 2 seperate fields.
I wasn't clear enough perhaps. I'm talking about the 
original file. If NtfsDisableLastAccessUpdate is set 
to 1 then the original file's LastAccessTime won't
be updated after a DOS copy command, but it will if
I use cp on an smbmounted volume. The destination file
will of course have both LastAccessTime and CretionTime
set to the current time. Like this:

   C:\Temp>dir /t:a a.xml
   12.12.2003  18:02              168.346 a.xml

   C:\Temp>copy a.xml b.xml
        1 Datei(en) kopiert.

   C:\Temp>dir /t:a a.xml b.xml
   12.12.2003  18:02              168.346 a.xml
   14.12.2003  15:59              168.346 b.xml

   C:\Temp>dir /t:c a.xml b.xml
   02.01.1997  16:24              168.346 a.xml
   14.12.2003  15:59              168.346 b.xml

   C:\Temp>dir /t:w a.xml b.xml
   04.12.2003  11:24              168.346 a.xml
   04.12.2003  11:24              168.346 b.xml

> I remember there is a option called 'dos filetime resolution' 
> for visual c problems, maybe this helps you.
This option was supposed to only fake the DOS FAT time
resolution of 2s and there's another one which forces
the faked 2s-resolution even when a Win client asks for
1s-resolution explicitly.

On the other hand, smbmount not being part of Samba at
all, I don't see how setting these options could affect
what is happening outside of Samba, in the kernel.

But thanks for the suggestion. I like out-of-box hints.

>> I wasn't clear enough perhaps.
>Maybe.
>
>> original file. If NtfsDisableLastAccessUpdate is set 
>> to 1 then the original file's LastAccessTime won't
>> be updated after a DOS copy command, but it will if
>> I use cp on an smbmounted volume.
>
> Now, that is strange. Setting the readonly attribute 
> would change this, but this may not be a solution for 
> your problem. Try to revoke the right to 'write extended 
> attributes' for everyone, that shouldn't interfere with 
> usual access, but stop the LastAccessUpdate.
Sounds self-explanatory. 
Must be something in Win registry?
I have to look it up.

>>>Now, that is strange. Setting the readonly attribute 
>
> attrib +r filename
> If you know how to use cmd.exe. If not use explorer, 
> right click, mark readonly.
>
>
>>> would change this, but this may not be a solution for 
>>> your problem. Try to revoke the right to 'write extended 
>>> attributes' for everyone, 
>
> Open security settings from a file, click the extended 
> button, edit and look up the list until you find 
> something similar. Mark deny. If you can't edit it 
> because it's all greyed out, it is an inherited right. 
> Create a new entry first or disable inheritance.
>
>
>> Must be something in Win registry?
> No.
> If you don't know what user rights exist on a NTFS 
> file system you really should look it up. Sorry that 
> my mind reading capabilities suffer with distance.
>
> Keep in mind that names and settings are translated 
> from german and could have different names in an 
> english version of windows.
>
> And before you ask, yes, it is tested.
That's great. It really works. Thanks, Holger.

I answered before it dawned on me that you meant the
"Write Extended Attributes" privilege in Advanced
File Security Properties. Sorry.