Samba issue?

JonEdwards · Post by **JonEdwards** » Fri Jan 06, 2006 4:41 pm

Hi all,

Are there any known issues concerning working folders and samba?

I'm on Windows XP Pro (edit: XP, not 2000), SP2 using Vault client v3.1.5 (3546) and have set one of my working folders to a directory on a SCO box that is exposed via samba.

I'm having consistant problems diff'ing and checking in certain files. Specifically, files that I don't own. Through other mechanims (Windows Explorer, VSS, notepad, etc) I can edit save, diff, etc these files. The specific error is "Invalid File or Directory attributes value".

Jon

lbauer · Post by **lbauer** » Fri Jan 06, 2006 5:05 pm

We've tested working folders about a year ago on various shares, including Samba and didn't encounter anything unusual. Are you having these problems only with files in the working folders on the Samba share?

When/where do you see the error messages about the invalid attributes?

JonEdwards · Post by **JonEdwards** » Fri Jan 06, 2006 5:32 pm

The first set of errors appeared when I tried to add an entire folder tree living on the samba drive. I received a host of errors of this type, one for each file that I did not "own".

I later received the same error when trying to do a diff and/or check-in any of these files. The files were definitely loaded into the repository - I was able to do a "get" into a local temp folder w/ no problem. Also of note, once the files where checked out and edited (via notepad) the diff worked, but the check-in still failed.

I have since restarted my Vault client. I now get a Status of "unknown" for every file on the Samba drive. I can't diff any of them and instead receive a "could not fine file..." error. I seem to be able to check out the files, regardless of owner. I can not use the context menu's "edit" function thanks to the "could not find file...." error. Finally, I can check in files that I happen to own, but not files that others own (again thanks to the could not find file error).

This probably isn't enough information, but it's Friday and I'm a little crispy.

When you tested did you use UNC names/paths for the samba working folders, or mapped drive letters?

Jon

lbauer · Post by **lbauer** » Mon Jan 09, 2006 8:43 am

Some questions --

Is this problematic behavior only with files you don't own? Are you experiencing any problems with files you do own?

Is the problem only with the working folder on the Samba drive? Are file operations from other working folders behaving as expected?

Where are you storing your cache files and working folder state/baseline files -- on your windows machine or Samba share?
(Location is set in Vault GUI Client under Tools->Options->Local Files->Cache/Backup Locations)

JonEdwards · Post by **JonEdwards** » Mon Jan 09, 2006 10:24 am

lbauer wrote:Some questions --

Is this problematic behavior only with files you don't own? Are you experiencing any problems with files you do own?

The files I own appear to be OK.

lbauer wrote:Is the problem only with the working folder on the Samba drive? Are file operations from other working folders behaving as expected?

Yes, this problem is specific to Samba drives. Files in working folders on my local machine, for example, are handled as expected.

lbauer wrote:Where are you storing your cache files and working folder state/baseline files -- on your windows machine or Samba share?
(Location is set in Vault GUI Client under Tools->Options->Local Files->Cache/Backup Locations)

They are stored in the User Local Settings Folder and Client Cache Folder respectively (all local).

Jon

JonEdwards · Post by **JonEdwards** » Mon Jan 09, 2006 11:10 am

FWIW, I created a new working folder on the samba machine and did a get-latest for all of the files in question. This set me as the owner of all of the folders and files. I then went in (through unix) and set the owner of a small set of files to be another developer.

I then tried a very simple test on one of the files I don't own:

1) Checkout version 1 of ".../getString.p"

- No problem. Local version is 1, remote version is 1 and status is blank.

2) Edit file outside of Vault.

- No Problem

3) Diff the file in Vault.

- No Problem, my changes show up (a good thing!).

4) Checkin the file.
- The following error popped up immediately:

"Updating the working folder failed for the following files:
$/Current/Server/framework/stringtrans/si/getString.p (Invalid File or Directory attributes value.)"

- The following messages were generated:

[1/9/2006 11:47:57 AM] Checking out file $/Current/Server/framework/stringtrans/si/getString.p
[1/9/2006 11:47:57 AM] Checked out file $/Current/Server/framework/stringtrans/si/getString.p
[1/9/2006 11:51:53 AM] Preparing data to begin transaction
[1/9/2006 11:51:53 AM] Beginning transaction
[1/9/2006 11:51:53 AM] Check in $/Current/Server/framework/stringtrans/si/getString.p
[1/9/2006 11:51:54 AM] Ending the transaction
[1/9/2006 11:51:54 AM] Transaction completed successfully

- The local version is still 1 while the remote version is now 2 and the Status is "Needs Merge".

5) Get Latest Version on the file in question, opting to overwrite modified local file, making all files read-only.

- Operation failed. Local version is 1, remote version is 2 and status is Needs Merge. The following messages written to the message window:

[1/9/2006 11:58:39 AM] Getting latest version of $/Current/Server/framework/stringtrans/si/getLastPage.p
[1/9/2006 11:58:39 AM] Finished get latest of $/Current/Server/framework/stringtrans/si/getLastPage.p
[1/9/2006 11:58:39 AM] Local file update for $/Current/Server/framework/stringtrans/si/getLastPage.p failed: System.ArgumentException: Invalid File or Directory attributes value.
at System.IO.File.SetAttributes(String path, FileAttributes fileAttributes)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, Boolean makeBackups, OverwritePrompt PromptData)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, OverwritePrompt PromptData)
at VaultClientOperationsLib.ClientInstance.ProcessGetFileRequests(GetFileInfo[] infos, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, Boolean updateHiddenFilesOnly, String ancestorFullPath, Boolean flat, String ancestorDiskPath, OverwritePrompt PromptData, Boolean isLabelGet, String currentPathToLabelItem, Int64 labelID, Boolean isRetry)

Jon

sterwill · Post by **sterwill** » Mon Jan 09, 2006 12:04 pm

The problem seems to be that you don't have permission to change the modes of these files (specifically, to set a file "read-only", in Windows terminology, which is probably mapped to removing all write bits on the Samba side). After files are added to a Vault repository from a mapped working folder, the Vault client needs to start managing these files, and depending on how you have your client options set, Vault will try to make the file read-only.

You can tell Vault not to make the files read-only by going to your client Options dialog, selecing the Concurrent Development Style category, and changing the value in the "Make Writable" drop-down to something other than "make all files read-only."

However, Vault will still attempt to change the dates and times on the files regardless of this setting in order to match the date the server thinks the latest version of these files was created at (this is required to work around the lack of modification time granularity on FAT filesystems). In this problem appears for you, try adding your files from a directory that is not a mapped working folder (Vault will not modify the files during add).

JonEdwards · Post by **JonEdwards** » Mon Jan 09, 2006 1:14 pm

OK, that makes sense. Even with the client set to make everything writable I still can't affect someone else's file. So, we'll have to find some other way to make this work.

In the meantime, we also have a requirement to shadow this entire tree. The shadow folder needs to reside on the samba drive. If I understand how the Vault server works, there's a web service that accepts the "shadow" request when the client performs the checkin and tries to write the updated file out to the appropriate shadow folder.

Assuming I'm correct, under what account does that service run and is it possible to change it to another ID that might have the appropriate network/samba permissions?

EDIT: I just found this: http://support.sourcegear.com/viewtopic.php?t=188. This should have everything I need.

Jon