Native Development

[Innovatology]

I'm trying to set the file modification time of files in the shared/documents folder for syncing purposes. It works for files that my app has created, but not for files that other apps have created nor for files that have been copied there via Wifi...

Here are the files in shared/documents:

$ pwd
/accounts/1000/shared/documents
$ ls -l _*.*
-rwxrw---- 1 nobody    1000_shared 23298 Sep 17 2011 _copied_via_wifi.txt
-rw-rw---- 1 100341000 1000_shared 11456 Nov 19 19:25 _created_by_docstogo.doc
-rw-rw---- 1 devuser   1000_shared 23298 Nov 19 18:20 _own_file.txt

Results of a touch command from the terminal:

$ touch _own_file.txt
$ touch _copied_via_wifi.txt
_copied_via_wifi.txt: Operation not permitted
$ touch _created_by_docstogo.doc
_created_by_docstogo.doc: Operation not permitted

I get the same results when calling utime() in C.

Of course I could make a 1:1 copy of the file, delete the original, rename the copy to the original, and then change the timestamp, but that would be a huge waste of resources and might fail if free space is limited. Creating a hard link won't work either, because the link has the same owner as the original.

Any ideas?

[smcveigh]

that's a good question.  I will inquire.

[smcveigh]

Ok, an update on this...

The documentation for utime() specifies:

The utime() function records the modification time for the file or directory identified by path.

If the times argument is NULL, the access and modification times of the file or directory are set to the current time. The effective user ID of the process must match the owner of the file or directory, or the process must have write permission to the file or directory, or appropriate privileges in order to use the utime() function in this way.

If the times argument isn't NULL, its interpreted as a pointer to a utimbuf structure, and the access and modification times of the file or directory are set to the values contained in the designated structure. Only the owner of the file or directory, and processes with appropriate privileges are permitted to use the utime() function in this way. The access and modification times are taken from the actime and modtime fields in this structure.

So from this, we can see that only the file owner can change the modification time to some time other than "now".  Have you confirmed whether utime("/path/to/file", NULL); succeeds?

It turns out that the QNX "touch" utility never invokes utime() in this manner, but always provides the current time as an argument.  This is a bug, and we'll look at fixing that.

Cheers,

Sean

[Innovatology]

Hi Sean,

Thanks for following up.

I realize that I am not the owner of the file, but as I do have write access and can write to file (thus changing its modification date), I was hoping to be able to change the modification date directly.

The work-around (copy-delete-rename) would have the same effect, plus make me owner of the file. But it would waste resources.

[smcveigh]

you CAN change the modification time directly. That is what I asked you to check by calling utime(filename, NULL);

The ability to change a file's time entries to an arbitrary date is restricted to the specific file owner.  This is a POSIX behaviour, and not something we are making up

Ceratinly opening and closing a file would be able to change the time... just not to an arbitrary value.

Cheers,

Sean

[Innovatology]

I understand, and calling utime with null works, but the use case calls for an arbitrary value. Too bad.

[smcveigh]

fyi, the info I am going off of is here:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/utimensat.html

and here:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html

[Innovatology]

That info is left out of the NDK API docs for utimes() and only vaguely mentioned in the description of one of the error return values.

I was under the impression that having write access to the file would qualify for "appropriate privileges". No such luck, I guess. I've lost count of the number of times I've hit a wall due to security restrictions for perfectly valid use cases. Back to the drawing board again :-(

Thanks for your help anyway, Sean.

[smcveigh]

no problem.

if you care to PM me the specific use case, maybe we can come up with another solution for your specific use case.

interestingly, the utime() docs are more specific regarding that situation.

http://developer.blackberry.com/native/beta/reference/com.qnx.doc.neutrino.lib_ref/topic/u/utime.htm...

it's interesting that utimes() only mentions it in the EACCES/EPERM section instead of up-front.