MPLAB "File has changed" message with files on a Samba share - Page 1
Forum section: electronics / general

author: David_AVD
author_rank: Super Contributor
timestamp: May 22, 2013, 06:07:07 am
content: Not sure if this really belongs here, but it is an issue that is confined to MBLAB for me.I'm using the most recent version of MPLAB on Windows 7 and the project files are stored on a Samba share (Debian server). I had the same issue with Windows XP.MPLAB often complains that one or more of the source files have been changed (and asks if I want to reload) even if I switch focus away and back to MPLAB. Of course if the file is not saved, accepting the reload option blows away the changes!I know that this is caused by a file time conflict between Windows and the Samba server, but have never managed to solve it over the past few years. Are there any Linux experts out there that can offer some advice on how to solve this?Moving the project files onto a local drive is not really a solution I want to go for, as I do jump around on different machines during the course of the day. That's the main reason for hosting them on the Samba server.

author: Psi
author_rank: Super Contributor
timestamp: May 22, 2013, 09:30:16 am
content: I'm not sure what it's called, but i do remember there's a config setting for which file date/time is supplied to windows by samba.

author: codeboy2k
author_rank: Super Contributor
timestamp: May 22, 2013, 10:36:17 am
content: maybe one of these two settings in your samba smb.conf fileCode:dos filetime resolutionUnder the DOS and Windows FAT filesystem, the finest granularity on time resolution is two seconds. Setting this parameter for a share causes Samba toround the reported time down to the nearest two second boundary when a query call that requires one second resolution is made to smbd.This option is mainly used as a compatibility option for Visual C++ when used against Samba shares. If oplocks are enabled on a share, Visual C++ usestwo different time reading calls to check if a file has changed since it was last read. One of these calls uses a one-second granularity, the other uses a twosecond granularity. As the two second call rounds any odd second down, then if the file has a timestamp of an odd number of seconds then the twotimestamps will not match and Visual C++ will keep reporting the file has changed. Setting this option causes the two timestamps to match, and Visual C++is happy.Default: dos filetime resolution = Falsedos filetimesUnder DOS and Windows, if a user can write to a file they can change the timestamp on it. Under POSIX semantics, only the owner of the file or root maychange the timestamp. By default, Samba runs with POSIX semantics and refuses to change the timestamp on a file if the user smbd is acting on behalf of isnot the file owner. Setting this option to True allows DOS semantics and smbd will change the file timestamp as DOS requires.Default: dos filetimes = Falsedos filetime resolutionseems promising.. perhaps MPLAB does sometime similar to VC++

author: David_AVD
author_rank: Super Contributor
timestamp: May 22, 2013, 11:54:52 am
content: Yeah, tried various combinations of those settings over the years with no luck.I may just have to move all projects over to the SVN system and use local (on the client PC) copies of the projects.

author: nctnico
author_rank: Super Contributor
timestamp: May 22, 2013, 02:29:09 pm
content: The latter is a much better solution. Working from a network share always gives weird side effects.I lost some very important files because the sysadmin didn't upgrade the server so there was no room to store the files. The IDE I used at that time wrote zero length files so effectively deleting the entire project. To add to the disaster the sysadmin didn't really worked out the backup scheme. He used 7 tapes for daily backups and one tape for a monthly backup. This meant he could go back only 7 days which caused my project to have dissapeared...

author: David_AVD
author_rank: Super Contributor
timestamp: May 22, 2013, 09:18:55 pm
content: I already use SVN for new projects, so migrating the (100's of) older ones will not take that much effort. A fix for the file time bug would have been nice in the meantime, but I can move projects into SVN as I need to anyway I guess.

author: C
author_rank: Super Contributor
timestamp: May 22, 2013, 11:59:55 pm
content: Could the problem be samba server time is different from your windows computers time? Your samba server might not be using NTP or a different time server from your windows computers?You could also be hitting a linux UTC time to windows utc time problem. Have you looked at the MBLAB reported errors?C

author: David_AVD
author_rank: Super Contributor
timestamp: May 23, 2013, 12:09:17 am
content: There's no "MPLAB errors" as such. Just the annoying "file has changed" pop-up.I opened the current project to my desktop today (via SVN) and no issues of course.

author: C
author_rank: Super Contributor
timestamp: May 23, 2013, 01:08:51 am
content: To me, if MPLAB pops up a message "file has changed" an that is not true then it is a program error.C

author: nctnico
author_rank: Super Contributor
timestamp: May 23, 2013, 01:25:14 pm
content: I have the same problem with other IDEs and software. Its just one of the mysterious ways Windows works.