Matlab Automation - Check if pdf is open and by which user.

Hello,

I'm currently running a code that produces .pdf files into a server folder. These files are used by many users (50+) and overwritten daily to reflect the most recent data available.

Sometimes, users forget to close the files when leaving and it prevents the file from being overwritten by the automation. Is there a way to check if the [filename '.pdf'] is in use and by which user (similar to the MS Office Read Only and Notify feature)?

[Walter Roberson]

Which OS is/are involved? Which networked file system?

[Richard]

The OS is Win XP SP3 and FS is FAT32.

[Jason Ross]

I assume the machine doing the file serving is Windows, as well? If so, I suggest moving to a setup where most clients connect via a read-only share (e.g. \\servername\data), and you update the file via a second share to the same location where you have read/write permission (e.g. \\servername\rwdata). On the (assumed) Windows server there are tools in Server Manager (Share and Storage Management) to see who has open sessons and files and disconnect them if need be. But these tools require admin permission on the server, which you may not be able to get -- and the approach I outline below will be more scalable and sustainable for the number of users you have accessing the data.

[Jason Ross]

As an added note, you can also use groups to set up who can read and write to the share if you want to approach it that way, as well. The main idea is that you make Read the way most people connect and Read-Write a special case when you need to update the data.

[Richard]

Thank you Jason, this information has been very helpful. I have been trying to implement a solution very similar to this but I have run into a problem...

The server(1) used to create .pdf files is not the same as the server(2) used for filehosting. I has administrative controls on the first server but not on the second. All of these files are refreshed atleast once daily.

Would it be possible to set permissions while creating the file and have them 'expire' at 12:01am? That way when the automation starts in the early am there would be no files to overwrite and it would always be successful when writing the pdf to disk.

The other option I could think of is giving server1 write permissions and giving all other users read-only permissions. Would it be possible for server1 to tell server2 to terminate all instances of the open file before overwriting?

If you have any other ideas it would be much appreciated.

Thanks again,

Richard

[Jason Ross]

In order for this to work, you will need some administrative control on the second server. The scheme where you have server2 put the files on server1 would accomplish this goal. The key is that you want to force most clients to get this read-only.

As for the permissions "expiring", once the file is opened by someone RW, you still have to be able to kick them off.

The simplest implementation of this is a batch file that does this (on server2 -- so you would need to work out something with the admin of this server)

net share /delete <sharename>

copy \\server1\mydoc.pdf <path_that_is_shared>

net share myshare <path_that_is_shared> /GRANT:user,READ

this would be run via scheduled task.

Alternatively, you could look into using the http protocol and forgetting the whole share thing. I think it's possible to present server1's directory on server2. Then the web server takes care of presenting the files and you won't have to worry about file locks.

Answer 1

[Jason Ross]

You are being too nice!

It sounds like this .pdf is intended to be used for read-only use. You can set up the share so that read-only permissions happen for the 50+ users who are accessing the document. The actual steps to accomplish this are unique on Windows or Linux, but are easy to set up. You could also investigate using using http, which sidesteps a lot of issues and makes your document accessible to any client that understands http and PDF, which includes not only PC's but also smartphones, so you can open up your data to a wider audience.

As for updating the data, that can be accomplished by a process running on the server itself or via a client that can read and write to the common location. This drops the number of clients that can hold the file open dramatically.

There are indeed means of finding this information out -- but they can require some level of administrative privilege, and even if you do find the people holding the file open, you're still going to need to somehow terminate the session -- and calling/emailing people to close their files is a non-scalable solution that eventually won't work, anyway -- for example, someone has to leave unexpectedly at 2PM and they aren't there to respond when your email comes at 5PM, and you still have to force them out somehow.

Other than the way mentioned above with read-only access, I've also used automation that deletes the share (which causes the clients to drop any locks), re-created the share, then updates the files. There are a lot of variations on this method -- such as creating the new file first, deleting the share, deleting the old file, then renaming the new file and putting up the share again.

Since you are doing this in automation, you can make this happen at 2AM, which scales nicely until you get people in different time zones who want your data :)

[Richard]

This sounds like a great solution! Thank you for the fast response.

I know how to set permissions on the files in Matlab, but how do you delete the share and reinitiate it? Do you know where I can find out more information about this process?

Also, I currently have the main automation running just after midnight, when the least amount of users are online.

Thanks in advance!

[Jason Ross]

It's a DOS command you can put in a batch file -- NET SHARE. You can delete and re-create the share using it. You could also shell out from MATLAB and call the command, too.

Answer 2

[Jan]

Does SysInternals:PsFile help?

[Richard]

I have tried using PsFile but the server running the automation is different from the one hosting the files.

I couldn't find a 'clean' solution using this method.